Red Hat Bugzilla – Bug 120093
dhclient dies if it doesn't get an answer from the dhcp server
Last modified: 2007-11-30 17:07:01 EST
Description of problem: The dhclient will die if the dhcp server is not available when it goes to renew its lease. So when the dhcp server does come back up it won't recover. Version-Release number of selected component (if applicable): dhclient-3.0pl2-6.14 How reproducible: everytime Steps to Reproduce: 1. start dhcp server 2. start up a dhcp client machine 3. confirm that network comes up with an ip served from server 4. stop dhcp server 5. after lease time dhclient will fail and die. Actual results: dhclient dies Expected results: dhclient should not die and restore the IP address when the dhcp server is available again. Additional info:
When a lease expires, dhclient is meant to try its DHCPDISCOVER until it fails for a 'timeout' parameter, configurable in dhclient.conf (default 1 minute). If this timeout expires, it will attempt to reuse any previous unexpired leases, and if there are none, by default it will sleep for a 'retry' interval, configurable in dhclient.conf (default 5 minutes) and begin its DHCPDISCOVER again - UNLESS the '-1' one-time option was specified on the command line, in which case it just gives up and exits. It seems that the /sbin/ifup script always invokes dhclient with the '-1' 'one-time' option: /sbin/ifup, line 248: if [ -n "${DYNCONFIG}" ]; then PUMPARGS=$PUMPARGS DHCPCDARGS="$DHCPCDARGS -n" DHCLIENTARGS="${DHCLIENTARGS} -1 -q -lf /var/lib/dhcp/dhclient-${DEVICE}.leases -pf /var/run/dhclient-${DEVICE}.pid -cf /etc/dhclient-${DEVICE}.conf" ^ and this is hardcoded, not configurable. Without this option, if the dhcp server does not respond, dhclient will sleep and retry forever until it does; with it, dhclient gives up the first time the server does not respond for the timeout. For dhcp clients that are meant to run unattended, and which depend on a dhcp server that may be temporarily down for maintenance, this would be nice behavior; otherwise the operator has to manually run ifup again on all the clients. So, there will now be a "PERSISTANT_DHCLIENT" option allowed in /etc/sysconfig/network-scripts/ifcfg-* If set to a value beginning with 'y', 'Y', or '1', then the '-1' option will be omitted from the dhclient options for that interface; else it will be included (the default). This will be in initscripts-7.61-1 .
To be consistent with other ifcfg-* options, you should also allow for "yes" and "YES". Question though, why have the -1 option be there by default? That seems counter intuitive makes RHEL/FC behave differently than Windows or SUSE.
"YES" "yes" "Yes" "yEs" "y" "Y" "1", etc. will all enable the option - this is just for convenience - I guess maybe it should handle "on" too. It is not the default because otherwise, if no DHCP server responds during boot up, the 'service network start' will hang indefinitely waiting for a response from the DHCP server. This is what the operator of an unattended rackmount server would want, but not what the "average" user would want.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-566.html
This isn't yet fixed in RHEL3. Advisory RHBA-2004:566-10 lists this bug as fixed for RHEL3, but only includes updated dhcp & dhclient packages. The PERSISTENT_DHCLIENT fix is in initscripts and the most recent initscripts for RHEL3 is 7.31.18.EL-1 which doesn't include this.