[Bug 974284] Re: invoking dhclient3 with -1 causes issue if no dhcp server available

[Stéphane Graber]

The patch is being applied but the result is still wrong. dhclient dies
after the lease expires instead of just keeping retrying indefinitely.

This also suggests that the fix in Ubuntu 12.10 doesn't actually work...
I'll have to take another go at that fix and update the patch in 12.10
and 12.04.

** Tags removed: verification-needed
** Tags added: verification-failed

** Changed in: isc-dhcp (Ubuntu Precise)
       Status: Fix Committed => Triaged

** Changed in: isc-dhcp (Ubuntu Quantal)
       Status: Fix Released => Triaged

** Changed in: isc-dhcp (Ubuntu Quantal)
     Assignee: (unassigned) => Stéphane Graber (stgraber)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/974284

Title:
  invoking dhclient3 with -1 causes issue if no dhcp server available

Status in “isc-dhcp” package in Ubuntu:
  Triaged
Status in “isc-dhcp” source package in Precise:
  Triaged
Status in “isc-dhcp” source package in Quantal:
  Triaged

Bug description:
  [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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/974284/+subscriptions