[Bug 974284] Re: invoking dhclient3 with -1 causes issue if no dhcp server available
stgraber at stgraber.org
Wed Sep 12 22:01:11 UTC 2012
I ended up just moving part of the patch a bit before so that it
actually does something.
I tested with "dhclient -1 -d" before and after confirming that when
there's no connectivity in the initial request it properly exits after a
minute but that if it gets a lease and then looses connectivity it'll
never exit again.
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
invoking dhclient3 with -1 causes issue if no dhcp server available
Status in “isc-dhcp” package in Ubuntu:
Status in “isc-dhcp” source package in Precise:
Status in “isc-dhcp” source package in Quantal:
A patch was designed to fix this bug back in precise but because of where it was put in debian/patches/00list it was actually being reverted at build time and so never fixing that bug.
In quantal, the reverting code in debian/rules is now gone, so it's
been applied ever since the 4.2 merge, so far without hearing any
problem with it.
1) Start dhclient -1 <interface> on a working network
2) Unplug the network cable or stop the DHCP server
3) Wait for the lease to expire
4) Check that dhclient tries to get a new lease and when failing, keeps trying
The original behaviour of -1 would make 4) try just a single time,
then give up, causing dhclient to remove all addresses and exit on a
machine that was unable to reach its dhcp server for >= expiry.
This change is definitely causing a slight change in behaviour, though based on this bug report and others, it's believe to be the wanted behaviour of -1 for most of our users.
The change itself has been applied to quantal without any regression and was tested on 12.04 in the past (before I messed up the ordering in the final upload ...).
The code change itself just makes "-1" use the same renewal behaviour as when called without "-1" (but still follows the standard "-1" behaviour for the first request).
In bug 838968, we modified ifupdown to invoke dhclient3 with '-1' as a parameter , and subsequently changed the default timeout of dhclient in isc-dhcp3 to from 60 seconds to 300 seconds .
The reason for this is that we now have a reliable "static-networking-
up" event that can be used for upstart jobs to start on, when static
networking is up. Here, static is any networking with an entry in
That event is used by cloud-init and other things that depend on
The fallout of this is that if for some reason a server (or cloud-
instance, or anything really), boots and does not obtain a dhcp
address in 5 minutes, then it will give up forever. The previous
behavior is that it would try forever.
This scenario isn't terribly unrealistic. A power fail could take out
a dchp server, cause a fsck, while the server came up 5 minutes before
the dhcp server was up.
Issue was originally raised in #openstack-dev by rmk around
* bug 838968: static-network-up event does not wait for interfaces to have an address
To manage notifications about this bug go to:
More information about the foundations-bugs