Ctrl-c abort of dhclient during rc.d start aborts all network
rwatson at FreeBSD.org
Wed Aug 31 20:42:59 GMT 2005
On Wed, 31 Aug 2005, Brooks Davis wrote:
> The wait should be 10 seconds plus some startup time.
It seemed a bit longer, but maybe I was counting fast. I'll time it next
time and see if there's more going on there.
>> (1) It would be good to configure lo0 first.
> Interfaces are configured in order of index by default. If lo0 were
> attached sooner, it would be configured sooner. I'm somewhat tempted to
> change it from it's current (apparently bogus) position in the startup
> process at SI_SUB_PROTO_IFATTACHDOMAIN to SI_SUB_INIT_IF/SI_ORDER_ANY
> and push the l2com attachments from SI_ORDER_ANY to SI_ORDER_MIDDLE.
> Strictly speaking I think lo(4) should be SI_SUB_PSEUDO, but moving it
> up so it attached first makes some sense given how critical it is.
> Alternativly, one could add code to sort the result of "ifconfig -l" to
> configure lo0 first.
I wonder if we could sed out lo0 from the automatic list and just
configure it first by fiat? While if_loop is in theory optional, it turns
out not to be very practical using our default boot scripts (since many
tools assume you can bind 0.0.0.0).
>> (2) If a dhclient is ctrl-c'd, it would be nice if the rest of the network
>> configuration continued.
> I don't see any code in the startup scripts that would cause them to
> exit on failure so the issue is probalby that the signal is being
> delivered to the /etc/rc.d/netif instance. I don't really know what the
> solution to that is.
Me neither. All I know is that I don't remember seeing this before.
>> The printing of '.'s in dhclient is also a bit excessive.
> Hanging with no output seems even less unhelpful. :( Longer term I want
> to get rid of syncronous calls to dhclient in the startup process, but I
> haven't had time to work on it and IMO, it's a bit late in the game for
I thought a bit about this, but concluded that we probably still have
components that assume a one IP (no more, no less) world, and slide by now
due to luck. A gradual conversion towards the assumptions of changing IPs
has been happening over time (vis natd -dynamic), but perhaps we need to
accelerate it some by forcing the issue in 7.x after 6.0 gets out the
Robert N M Watson
More information about the freebsd-current