# [SOLVED] dhclient filling /var/log/messages with help info

## jw5801

Whenever dhclient is run, either manually or by a network manager, it prints it's entire help message to /var/log/messages, even if it's run with the '-q' switch, as can be seen below:

```
Aug 20 09:38:59 Andornor ADDRCONF(NETDEV_UP): wlan1: link is not ready

Aug 20 09:39:03 Andornor dhclient: Internet Systems Consortium DHCP Client V3.1.2p1-Gentoo

Aug 20 09:39:03 Andornor dhclient: Copyright 2004-2009 Internet Systems Consortium.

Aug 20 09:39:03 Andornor dhclient: All rights reserved.

Aug 20 09:39:03 Andornor dhclient: For info, please visit http://www.isc.org/sw/dhcp/

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: Bind socket to interface: No such device

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: If you did not get this software from ftp.isc.org, please

Aug 20 09:39:03 Andornor dhclient: get the latest from ftp.isc.org and install that before

Aug 20 09:39:03 Andornor dhclient: requesting help.

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: If you did get this software from ftp.isc.org and have not

Aug 20 09:39:03 Andornor dhclient: yet read the README, please read it before requesting help.

Aug 20 09:39:03 Andornor dhclient: If you intend to request help from the dhcp-server@isc.org

Aug 20 09:39:03 Andornor dhclient: mailing list, please read the section on the README about

Aug 20 09:39:03 Andornor dhclient: submitting bug reports and requests for help.

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: Please do not under any circumstances send requests for

Aug 20 09:39:03 Andornor dhclient: help directly to the authors of this software - please

Aug 20 09:39:03 Andornor dhclient: send them to the appropriate mailing list as described in

Aug 20 09:39:03 Andornor dhclient: the README file.

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: exiting.

Aug 20 09:39:03 Andornor dhclient: Internet Systems Consortium DHCP Client V3.1.2p1-Gentoo

Aug 20 09:39:03 Andornor dhclient: Copyright 2004-2009 Internet Systems Consortium.

Aug 20 09:39:03 Andornor dhclient: All rights reserved.

Aug 20 09:39:03 Andornor dhclient: For info, please visit http://www.isc.org/sw/dhcp/

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: Bind socket to interface: No such device

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: If you did not get this software from ftp.isc.org, please

Aug 20 09:39:03 Andornor dhclient: get the latest from ftp.isc.org and install that before

Aug 20 09:39:03 Andornor dhclient: requesting help.

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: If you did get this software from ftp.isc.org and have not

Aug 20 09:39:03 Andornor dhclient: yet read the README, please read it before requesting help.

Aug 20 09:39:03 Andornor dhclient: If you intend to request help from the dhcp-server@isc.org

Aug 20 09:39:03 Andornor dhclient: mailing list, please read the section on the README about

Aug 20 09:39:03 Andornor dhclient: submitting bug reports and requests for help.

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: Please do not under any circumstances send requests for

Aug 20 09:39:03 Andornor dhclient: help directly to the authors of this software - please

Aug 20 09:39:03 Andornor dhclient: send them to the appropriate mailing list as described in

Aug 20 09:39:03 Andornor dhclient: the README file.

Aug 20 09:39:03 Andornor dhclient: 

Aug 20 09:39:03 Andornor dhclient: exiting.

Aug 20 09:39:03 Andornor ADDRCONF(NETDEV_UP): wlan1: link is not ready

Aug 20 09:39:03 Andornor ADDRCONF(NETDEV_UP): wlan1: link is not ready

Aug 20 09:39:04 Andornor ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready

Aug 20 09:39:05 Andornor dhclient: Internet Systems Consortium DHCP Client V3.1.2p1-Gentoo

Aug 20 09:39:05 Andornor dhclient: Copyright 2004-2009 Internet Systems Consortium.

Aug 20 09:39:05 Andornor dhclient: All rights reserved.

Aug 20 09:39:05 Andornor dhclient: For info, please visit http://www.isc.org/sw/dhcp/

Aug 20 09:39:05 Andornor dhclient: 

Aug 20 09:39:06 Andornor dhclient: Listening on LPF/wlan1/00:19:7e:72:d7:c8

Aug 20 09:39:06 Andornor dhclient: Sending on   LPF/wlan1/00:19:7e:72:d7:c8
```

I don't think this is a new thing, I'm just in the process of attempting to clean up anything that spams the system log. I've looked through the dhclient documentation thinking that there might be a configuration option to control what gets posted to syslog, but I can't see anything.

Has anyone else been annoyed enough by this to try and fix it?

I'm using net-misc/dhcp-3.1.2_p1:

```
jw@Andornor ~ $ eix ^dhcp$

[I] net-misc/dhcp

     Available versions:  3.1.1 3.1.1-r1 ~3.1.2 3.1.2_p1 [M]~4.0.1 [M]~4.1.0 {doc ipv6 kernel_linux minimal selinux static vim-syntax}

     Installed versions:  3.1.2_p1(23:23:13 10/08/09)(kernel_linux -doc -minimal -selinux -static)

     Homepage:            http://www.isc.org/products/DHCP

     Description:         ISC Dynamic Host Configuration Protocol
```

Last edited by jw5801 on Sat Aug 22, 2009 5:05 pm; edited 1 time in total

----------

## causality

I could be wrong but I believe that dhclient doesn't produce that message unless it quits (fails) due to an error.  So, that text it added to your logfile was really just a symptom.  The first line of that output suggests that this is what happened:

```
Aug 20 09:38:59 Andornor ADDRCONF(NETDEV_UP): wlan1: link is not ready 
```

Farther down, dhclient output this error message (7th line from the top of your output):

```
Aug 20 09:39:03 Andornor dhclient: Bind socket to interface: No such device 
```

If you fix that, it should prevent dhclient from producing such large amounts of output.  Unfortunately, without more information I don't know what is actually causing that error but I can suggest a few things that may help.

If "wlan" means you're on a wireless network, it's possible that connecting to that network takes a while and dhclient is trying to do its job before you have done so.  That could be solved by having dhclient execute when the network is actually up.  You could also try a different DHCP implementation (like net-misc/dhcpcd instead of net-misc/dhcp) to see if it's less "noisy".

If that is not the case, there are some other places to begin.  If that machine can successfully use your network and everything functions, list the network devices by typing "ifconfig" into a root shell.  If not, the first thing I would check is that your network driver(s) (i.e. the modules or the ones built into the kernel) are loading correctly; the easiest way to do that is to check the output of dmesg after a fresh reboot.

```
dmesg | less
```

That will produce a lot of non-network related output.  You can search for the device names from the output of "ifconfig" like "wlan" or "eth" (in "less", press '/' to search for a string) that you would normally expect to find in the output of the "ifconfig" command.

Assuming those are loading correctly, check your dhclient.conf file.  Look for a line beginning with "interface" like "interface wlan1".  Check that it matches one shown in the output of "ifconfig".  If it doesn't, then that would explain your error message and correcting the interface name should fix it.  

If everything in that file looks good then it's possible dhclient is trying to execute before the interface is actually up.  The output of this command may be helpful (may need to be root):

```
rc-status -a
```

DHCP should be listed under "default" and should not be listed under "boot".  You probably have "net.lo" under boot and other interface scripts like "net.eth0" and "net.wlan1" should show up under "default".

----------

## jw5801

 *causality wrote:*   

> I could be wrong but I believe that dhclient doesn't produce that message unless it quits (fails) due to an error.  So, that text it added to your logfile was really just a symptom.  The first line of that output suggests that this is what happened:
> 
> ```
> Aug 20 09:38:59 Andornor ADDRCONF(NETDEV_UP): wlan1: link is not ready 
> ```
> ...

 

I use wicd to connect to various wireless networks, and I'm seeing this during normal operation, not just during boot. The interface is well and truly up, I can connect perfectly well and there aren't any actual usability problems.

Hmm, I think this might be a bug in wicd. If I stop the wicd daemon and run "ifconfig wlan1 up && dhclient wlan1" myself, everything is fine. If I try running "dhclient wlan1" whilst the wicd daemon is running, I get spammed error messages in my log (but not to STDOUT, interestingly enough, that just displays the normal expected messages, resulting in me obtaining an ip). Also when I tell wicd to connect to a network, I get the help messages spammed in my log. Everything successfully connects, however, so I'm not sure what's going on there.

I'll install the most up-to-date version of wicd and see if I can still observe this.

----------

## causality

Just a personal preference, but I'd also try replacing net-misc/dhcp with net-misc/dhcpcd.  I'm not sure if it's a drop-in replacement but it shouldn't be difficult to configure.  That may or may not solve the cause of the error, but is likely to handle it in a less "noisy" fashion.  Like BIND, ISC's DHCP (net-misc/dhcp) is a reference implementation so it's probably overkill for your needs.  This page also seems to indicate that at least sometimes, dhcpcd is a better match for wicd.

 *Quote:*   

> Hmm, I think this might be a bug in wicd. If I stop the wicd daemon and run "ifconfig wlan1 up && dhclient wlan1" myself, everything is fine. If I try running "dhclient wlan1" whilst the wicd daemon is running, I get spammed error messages in my log (but not to STDOUT, interestingly enough, that just displays the normal expected messages, resulting in me obtaining an ip).

 

I guess the real question there is, what is really happening when you stop the wicd daemon?  Is it possible that it's releasing some kind of lock on the device when it shuts down?  What confuses me is that you would think that something like wicd would handle DHCP automatically, on an as-needed basis.  If that's the case, it may not be unusual that manually executing DHCP fails and won't succeed as long as wicd is running.

----------

## jw5801

 *causality wrote:*   

> Just a personal preference, but I'd also try replacing net-misc/dhcp with net-misc/dhcpcd.  I'm not sure if it's a drop-in replacement but it shouldn't be difficult to configure.  That may or may not solve the cause of the error, but is likely to handle it in a less "noisy" fashion.  Like BIND, ISC's DHCP (net-misc/dhcp) is a reference implementation so it's probably overkill for your needs.  This page also seems to indicate that at least sometimes, dhcpcd is a better match for wicd.

 

Well, I updated to 1.6.3, which seemed to then remove the spam from the log, however due to an unknown problem with dhclient, wicd was completely unable to attain an IP. So I've switched to dhcpcd and I'm finding it much nicer so far!

 *Quote:*   

>  *Quote:*   Hmm, I think this might be a bug in wicd. If I stop the wicd daemon and run "ifconfig wlan1 up && dhclient wlan1" myself, everything is fine. If I try running "dhclient wlan1" whilst the wicd daemon is running, I get spammed error messages in my log (but not to STDOUT, interestingly enough, that just displays the normal expected messages, resulting in me obtaining an ip). 
> 
> I guess the real question there is, what is really happening when you stop the wicd daemon?  Is it possible that it's releasing some kind of lock on the device when it shuts down?  What confuses me is that you would think that something like wicd would handle DHCP automatically, on an as-needed basis.  If that's the case, it may not be unusual that manually executing DHCP fails and won't succeed as long as wicd is running.

 

Yeah, I wouldn't find it that unusual for dhclient to fail, however it didn't appear to be. It almost seemed as though when I ran it manually the lease was released and a new one was attempted to be negotiated, however as soon as wicd realised that the lease had been released it attempted to run dhclient to obtain a new one, which then resulted in the spam in the log file. The active dhclient in my shell didn't error out, but there was still the errored version in the syslog.

Ah well, it seems there are plenty of fun conflicts with dhclient and wicd, so I'll just jump ship and run with dhcpcd from now, and mark this solved.

----------

