[pkg-dhcp-devel] Bug#675372: Bug#675372: isc-dhcp-client: dhclient wastes one minute at boot time on an unplugged link

[Alessandro Rimoldi]

hi

please don't cc: me on this bug report.

i can't say more than the fact that it happens to me on a similar
configuration as the one reported in the bug report.

my system has only packages from debian testing.

ciao
a.l.e

On Sun, Jun 17, 2012 at 7:07 AM, Andrew Pollock <apollock at debian.org> wrote:
> 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 <apollock at 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJP3WYHAAoJEFHf2Ts++3nvZL4P/2+G6SBODTtb9Bzo/ss2SID4
> 7ldkcS1Eddo3RekHRKRanbJZV0HIaCEjGPryTgrnRJrq9rYJENxKxFIjfZC4pD27
> lKj4mf1ButN2pzfCPvDb3mI1j+Jrncux5nM+JwtrCflD/eLyWoPJEWufdYP6G0XC
> L3BhXVbgr+dY4k/9V3QJLSINSdnuPE7zN2BFD9lJPBw+0Xln2syLrdG4fD1R6rSO
> hrDC2LqiRnhXvafdJkv48gKiWlMBeTvyCkQLN7fpCj5EsrB7JtXZsJ2OfFH8uJ2D
> TgW6Ekai2QGK8eGhHBhRTk3fwwfRI3+wjIPd8HQjzeXuNaW/qbA+HKUhjFEiDYYT
> rskrO2rjk7PBQ3QdUwXtEilCnGwPqZ/UWZqmvrBk7WTVcI/45KEpLEUQWBMBFRIU
> I06AA73pYaNcx0CbtncAdSnHXdhc6k2NFH3KksGCTywYNrnFNfcC/FzMns8Z5Py1
> b6cGY+u/Ve9dULN0z20FmTQlu2M0w0tuZTI8hdlnu5mIdr/guvd24GUISrLRTTk1
> O0S2KYOmWXsUc2eC0P7ZtD4BydoJpBubRJ+BMg9GepXwsXXN1H4TuGDUHkMCca9R
> WeMp9rYiQUxAGv5U5WnG4NDCsV/q5GLQCQbVB6C/mkbggA27P4OpnRdy2sWDrPSn
> /AFWwWuYWlM45RcfUhdk
> =4vMk
> -----END PGP SIGNATURE-----
>