Bug 210192 - dhcpclient terminates if DHCP server is unavailable
dhcpclient terminates if DHCP server is unavailable
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dhcp (Show other bugs)
4.4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-10 14:08 EDT by Guenther Thomsen
Modified: 2008-02-28 15:03 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-28 15:03:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Guenther Thomsen 2006-10-10 14:08:52 EDT
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
again. 

Version-Release number of selected component (if applicable):
Internet Systems Consortium DHCP Client V3.0.1

How reproducible:


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
 
Actual results:
2. in 10 out of 13 cases, the dhcpclient process terminated.

Expected results:
see above, steps to reproduce (the dhcpclient should not terminate)

Additional info:
Comment 1 David Cantrell 2007-10-31 15:10:20 EDT
Is this happening with RHEL5 or a later RHEL4 release?
Comment 2 RHEL Product and Program Management 2007-11-28 23:24:02 EST
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
release.
Comment 3 David Cantrell 2008-02-13 21:06:51 EST
Unable to reproduce on latest versions of RHEL 4 and RHEL 5.
Comment 4 David Cantrell 2008-02-13 21:07:28 EST
Wait, scratch that.
Comment 5 David Cantrell 2008-02-13 21:27:15 EST
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
for sure.

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.
Comment 6 Guenther Thomsen 2008-02-28 14:26:54 EST
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
not.  

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. 
Comment 7 David Cantrell 2008-02-28 15:03:31 EST
(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 
add:

PERSISTENT_DHCLIENT=yes

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.

Note You need to log in before you can comment on or make changes to this bug.