On Sat, Jun 16, 2012 at 11:17:13AM +0200, Andrew Shadura wrote: > Hello, > > On Fri, 15 Jun 2012 21:30:12 -0700 > Andrew Pollock <apoll...@debian.org> wrote: > > > I may have spoken too soon. There's no noticeable time difference > > between a run of dhclient with or without the -1 option (although I'd > > have thought we'd want dhclient to hang around in the background in > > case a cable was subsequently plugged in, so I still don't think that > > adding -1 to how ifup invokes dhclient is a particularly desirable > > thing) > > Well, I don't really know what is worse: to have ifupdown to think it's > okay and mark our interface as being up, but not having it really > configured (so we have some inconsistency), or to require a user to run > ifplugd or something to bring it back up when the link is available > again or to run ifup again by hand. Probably I will just implement some > kind of callbacks in the next version of ifupdown so we can make it > really working.
Hey Andrew, thanks for chiming in. So if I'm understanding what you've said correctly, you're trying to solve the problem where ifup runs dhclient, dhclient fails to get a lease, but ifup considers the interface up? What about the scenario where a server boots and *something* between it and the DHCP server is temporarily down (including the DHCP server) so it doesn't get a lease at ifup time, but the dhclient that persists in the background eventually gets one when the temporarily issue is resolved? With the -1 option, an administrator is going to have to physically visit the server to rectify the situation, whereas without the -1, it'll sort itself out (eventually). Not that any of this is looking relevant to #675372, as I can reproduce the problem without the -1 option. regards Andrew
signature.asc
Description: Digital signature
