** Description changed: - In bug 838968, we modified ifupdown to invoke dhclient3 with '-1' as a - parameter [1], and subsequently changed the default timeout of dhclient - in isc-dhcp3 to from 60 seconds to 300 seconds [2]. + [rational] + 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. + + [test case] + 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. + + [regression potential] + 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 [1], and subsequently changed the default timeout of dhclient in isc-dhcp3 to from 60 seconds to 300 seconds [2]. 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 /etc/network/interfaces. That event is used by cloud-init and other things that depend on network. 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 2012-04-05T06:42:19 [3] -- [1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ifupdown/precise/revision/56 [2] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/isc-dhcp/precise/revision/32 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2012-04-05.log Releated bugs: * bug 838968: static-network-up event does not wait for interfaces to have an address
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/974284 Title: invoking dhclient3 with -1 causes issue if no dhcp server available To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/974284/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
