Red Hat Bugzilla – Bug 210192
dhcpclient terminates if DHCP server is unavailable
Last modified: 2008-02-28 15:03:31 EST
Description of problem: 10 of 13 hosts sporting RHEL-AS 4update4 fell off the
net after the DHCP server was unreachable for a few hours (>max-lease-time). The
dhclient process was not running on the hosts anymore, so on each the interface
had to be shut down and brought back on-line manually (using ifdown/ifup), which
restarted the dhcpclient. I don't know, why the dhcpclient process did not fail
on the 3 remaining hosts. In the same LAN, 12 Windows 2003 hosts managed to keep
(or better: reacquire) their IP address.
While it is expected that DHCP clients give up their IP address and hence
accessibility, if the DHCP server is not reachable for a time period longer that
the max. lease time, they should continue to send DHCP requests, so that the
network interface can be properly reconfigured, once ther server is available
Version-Release number of selected component (if applicable):
Internet Systems Consortium DHCP Client V3.0.1
Steps to Reproduce:
1.disable DHCP server in broadcast domain for longer than max-lease-time
2.verify that DHCP client releases IP address (unconfigures network interface)
_and_ still periodically send DHCPREQUESTS
3.enable DHCP server again
4.DHCP clients should then in reasonable time reacquire a lease and reconfigure
the network interface
2. in 10 out of 13 cases, the dhcpclient process terminated.
see above, steps to reproduce (the dhcpclient should not terminate)
Is this happening with RHEL5 or a later RHEL4 release?
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Unable to reproduce on latest versions of RHEL 4 and RHEL 5.
Wait, scratch that.
False alarm. The behavior you are witnessing is expected. The 10 out of 13
problem indicates a possible networking issue with your LAN, but I can't tell
What I do know is that dhclient is behaving as it should. On renewal, it
attempts to renew the lease it has from the server. If that fails, it iterates
over the lease database trying to find a valid one it has cached from previous
runs. If it is able to renew one, it uses it. Failing that, dhclient starts
discovery over again and if no lease can be obtained, the client exits.
Having DHCP clients depends on a reliable DHCP server being available. There's
no way around that.
Please re-read the description of the defect. There it is stated, that clients
are expected to release their lease after it expires. It is however not expected
that they give up acquiring a lease just because the last expired. Further an
example was given of a competing OS which behaves differently and more according
to (this) user's expectations.
The dhcp server was in this case not at fault, but a network switch (actually
it's confguration, iirc - it's been a while). Replacing/fixing the switch was
painless - having to log in to 10 machines just because the dhclient gave up was
This bug seems actually to be a misconfiguration in the way dhclient is used,
rather than a defect in the code of dhclient, i.e. the command line option '-1'
is given, which requests the tool to exit after it failed to acquire a lease.
Correct behavior can be expected by not using that command line option.
(In reply to comment #6)
> This bug seems actually to be a misconfiguration in the way dhclient is used,
> rather than a defect in the code of dhclient, i.e. the command line option '-1'
> is given, which requests the tool to exit after it failed to acquire a lease.
> Correct behavior can be expected by not using that command line option.
dhclient is behaving as it should. If you want to have dhclient start without the -1 option, you need to
To the ifcfg-ethX file for your interface in the /etc/sysconfig/network-scripts directory.
For any further questions, please contact your Red Hat support representative.