# dhcpcd error spamming logs

## Havin_it

Hi,

I seem to have hit a bug with dhcpcd-5.5.6. At least, that was (I think) the only upgrade of it before my last reboot, which is when I noticed the problem.

A number of services on my server stopped running, and I discovered that /var/log/daemon.log, /var/log/debug and /var/log/syslog had each grown to several GB thanks to the following line spewing many times a second:

```
May 26 14:47:11 hazel dhcpcd[1400]: received signal -1, but don't know what to do with it
```

The main thing that's odd here is I don't even know why dhcpcd is running, because I have a static configuration. Here's what's in /etc/conf.d/net:

```
# This first line was only added during debugging, but it made no difference anyway

modules="!dhcpcd"

config_eth0="192.168.2.7 netmask 255.255.255.0"

routes_eth0="default via 192.168.2.1"

dns_servers_eth0="192.168.2.1"

dns_search_eth0="mydynhost.dyndns.org"
```

The only other thing that's been going on recently is I was briefly using dnsmasq (which I already use for DNS) as a DHCP server, but I'd already stopped doing so when I found this problem.

I'm a little confused about whether my config above is correct. It's worked fine for some time, dhcpcd may or may not have been running previously but it certainly wasn't spamming errors. The Gentoo handbook talks purely about using /etc/conf.d/net for net setup, but I also note NeddySeagoon saying here that if you're on baselayout2 (which I am), you should be using /etc/conf.d/network only. What's the truth? Is the handbook out of date?

I should add I don't have the dhcpcd initscript in any runlevel, no other services depend on it that I can see, and it says it's stopped. Yet init is invoking it somewhere, and keeps doing so unless I actually unmerge it (which is not a desirable solution as I still want to keep it handy for possible use).

What gives?

----------

## Bones McCracker

Verify that you don't have dhcpcd in one of your runlevels and that you didn't add a dependency on it to one of your other initscripts.

You should be using /etc/conf.d/net.  I believe the plan was to do away with it, in favor of a simpler set of scripts configured in /etc/conf.d/network, but that plan has been reversed, and I believe the plan is now to continue using /etc/conf.d/net.

----------

## Havin_it

No, it's definitely not called by anything I've explicitly done. /etc/init.d/net.lo is the only initscript that mentions it, and that is as a fallback if there's no config for an interface, which there is. Is anything wrong with the config above?

----------

## Bones McCracker

I don't see anything wrong with it.

I'm sure you know this, but just in case:

You can check your actually running services with rc-status.

You can check your rc service runlevel configuration with 'rc-update show'.

Just confirm the following:

You do not have dhcpcd in any of your runlevels.

You do not have any dependencies on dhcpcd in any of your initscripts.

You are not using net-dns/openresolv.

You are not running wpa-supplicant, network manager, or any crap like that.

You do not have a file /etc/conf.d/network, or have commented out everything in it.  

You do not have the service "network" in any of your runlevels.

You do have a symlink  /etc/init.d/net.eth0  --> /etc/init.d/net.lo

You do have service net.eth0 in your default runlevel (or whatever your working runlevel is).

If all of those are true, then I would assume (be forewarned; I'm not very smart) that openrc is somehow firing up dhcpcd as a default means to provide the generic "net" service (perhaps during the boot runlevel, when net.lo is run, since your net.eth0 is probably running in your default runlevel and has not yet provided "net").  Personally, I would just uninstall dhcpcd.  It's easy enough to reinstall it if you're going to use it.

However, if you want to keep it, you might be able to suppress the behavior I am guessing is happening by temporarily telling openrc that dhcpd does not provide "net".  You should be able to achieve that by commenting out the following line in /etc/init.d/dhcpcd:

```
provide net
```

Alternatively, if you don't want to monkey with the initscript, you should be able to achieve the same thing by following the guidance in /etc/rc.conf, which says you can create /etc/conf.d/<service> files with service-specific configuration variables.  Based on the guidance there, you should be able to create file /etc/conf.d/dhcpcd containing the following:

```
rc_provide="!net"
```

I'm as likely to be right as wrong about this, but since no one else has responded, there you have it.

----------

## Havin_it

OK, I confirm for the record that I know of the rc-* tools and I pass the checklist.  I don't think the dhcpcd initscript is invoked (status: stopped and not mentioned in any other files), so I guess it must be net that's doing it, calling dhcpcd directly. (Seems it probably *should* call the initscript -- if it felt it needed to -- but perhaps the openrc folks haven't adapted to this change yet.) At any rate, clobbering the dependency (if there was one) wouldn't feel all that elegant however I went about it.

I'll move net.eth0 from default to boot and see if that helps. I think it was in boot on my last server so that should be a safe move.

Using a different client is a thought too. I had good experience with pump in the past, but now it conflicts with distcc  :Sad:  I could give dhclient a whirl though.

----------

## Bones McCracker

Or you could just uninstall it since you're not using it.  As I say, it's not like you have to build Stonehenge or something to get it back if you decide to go back to using dynamic address assignment.

You might also consider writing your own network script (and not using net.lo and symlinks to it).  The Gentoo scripts are designed to be flexible and accommodate a wide variety of alternatives, but there's nothing stopping you from just writing your own little initscript which executes the commands you would manually use to bring up and configure your two interfaces.  I have done this before when I was trying to do something weird with wpa_supplicant.

----------

## Havin_it

Yeah, I already have a few "shims" of my own stuck in init, and it's not the end of the world if I have to keep dhcpcd uninstalled (it's already quickpkg'd anyway) but I still want to get to the bottom of it as it might be a bug.

I moved net.eth0 to boot runlevel and found that, although dhcpcd wasn't running, it *had* apparently run and overwritten my resolv.conf, which caused other problems. If it's not the dhcpcd initscript, and it *shouldn't* be net either (from my config), is udev maybe doing it by itself? (udev is rapidly becoming the bane of my life lately)

Also, why is the error output going in 3 different logfiles? Can I prevent that?

----------

## Bones McCracker

 *Havin_it wrote:*   

> Yeah, I already have a few "shims" of my own stuck in init, and it's not the end of the world if I have to keep dhcpcd uninstalled (it's already quickpkg'd anyway) but I still want to get to the bottom of it as it might be a bug.
> 
> I moved net.eth0 to boot runlevel and found that, although dhcpcd wasn't running, it *had* apparently run and overwritten my resolv.conf, which caused other problems. If it's not the dhcpcd initscript, and it *shouldn't* be net either (from my config), is udev maybe doing it by itself? (udev is rapidly becoming the bane of my life lately)

 

Is it the dhcpcd initscript that's being run, or is openrc itself starting the dhcpcd daemon?  I think if you're using the net.* scripts, it's the latter.

I still don't understand why dhcpcd is running.  Make sure you've commented out everything in /etc/conf.d/network if you have that file.  You might also try preventing it from being hotplugged, although I don't see why that would be happening (in /etc/rc.conf):

rc_hotplug="!dhcpcd !net.eth0"

I think that openrc itself will overwrite the resolv.conf file if there are any 'dns_*' entries in /etc/conf.d/net.  Since your entries are specific to eth0, I'd expect that to be happening when eth0 is brought up and not at boot, but I suppose that just demonstrates that I don't understand how openrc works.  At any rate, if you want resolv.conf to remain static and not be over-written at all, you might try deleting all 'dns_*' entries from your /etc/conf.d/net file.  That way, if no dhcp client is run, I think it might remain intact.

 *Havin_it wrote:*   

> Also, why is the error output going in 3 different logfiles? Can I prevent that?

 

That would be controlled by your syslog configuration (and whether or not you uncommented the rc-log stuff in /etc/rc.conf).

----------

