[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)


Steven Chamberlain <steven@pyro.eu.org> (2014-08-13):
> On 13/08/14 18:05, Cyril Brulebois wrote:
> > What I'd like to get figured out is what changed between images that
> > weren't hitting this problem, and the newly published ones.
> What changed is dhclient from isc-dhcp-client-udeb gained a signal
> handler that responds to SIGKILL by releasing the DHCP lease and
> deconfiguring the interfaces.  I've just tested that the version in
> wheezy d-i didn't trap the signal;  Linux udhcpc doesn't either.

thanks. Knowing where/when/why a regression happens is quite important
to me.

> This is a 'feature' introduced in ISC DHCP 4.3.0, which first reached
> testing on 2014-07-16;  I've tested that d-i Alpha 1 wasn't affected by
> this bug (dhclient is killed but the interface stays configured) :
> > @@ -681,6 +692,10 @@ main(int argc, char **argv) {
> >         dmalloc_outstanding = 0;
> >  #endif
> >  
> > +        /* install signal handlers */
> > +       signal(SIGINT, dhcp_signal_handler);   /* control-c */
> > +       signal(SIGTERM, dhcp_signal_handler);  /* kill */
> > +
> (from
> http://anonscm.debian.org/gitweb/?p=pkg-dhcp/isc-dhcp.git;a=commitdiff;h=b2a56ecb808768dbc5bd4be60fcf9c9f93d8e802#patch16
> )
> Either way, netcfg killing the DHCP client seems wrong to me, because
> I'd expect the kind of issues Philipp Kern described;  if you're going
> to use DHCP, you ought to renew your lease and not let it expire?

Now, I think there are several questions to answer:
 1. What were the reasons for having arch-dependent dhcp clients?
 2. Are those reasons still valid?

=> Maybe think about moving to a single client if possible, at least for
   consistency's sake (and probably maintenance costs).

The answer to the first question is likely answered by looking at some
git history, and possible links to bug reports. As for the second, we'll
likely need porter input.

 3. Is the current netcfg behaviour correct?

=> The answer is probably “no”, based on Steven's and Phil's opinion;
   and while I haven't looked into it yet, I'm pretty convinced by
   Phil's points.

Of course we could probably apply Steven's patch, but it seems
appropriate to me to (also) take some time and investigate questions 1+2
above while we're on that topic.


Attachment: signature.asc
Description: Digital signature

Reply to: