Ctrl-c abort of dhclient during rc.d start aborts all network configuration

[Robert Watson]

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 
> 6.0.

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 
door?

Robert N M Watson