The rc.d mess strikes back

[Mike Makonnen]

Brooks Davis wrote:
> On Wed, Mar 04, 2009 at 12:04:06AM -0800, Garrett Cooper wrote:
>> On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen
>> <mmakonnen at gmail.com> wrote:
>>> On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis <brooks at freebsd.org> wrote:
>>>> I don't have much time to debug this, but I've not had problems with
>>>> services starting too early on the systems I've been running with async
>>>> dhcp. ?If there is a problem with the wait process we need to actually
>>>> debug it. ?If the wait for a route/running interface isn't sufficent we
>>>> should try to figure out what is. ?Synchronous dhcp sucks and yeilds
>>>> justifed user complaints so it would be nice to kill it off. ?I switched
>>>> the default because it worked for me and I hoped that people would help
>>>> find and fix edge cases.
>>> Can you elaborate why synchronous DHCP sucks ?
>> The only reason I could see is bringup time. Am I correct in this assumption?
> 
> If you use synchronous DHCP then every interface that wants to try to
> get a DHCP address if it has link needs to run through the full link
> timeout at boot.  On a laptop this is annoying and generally pointless.

Ok, I just turned synchronous dhclient on locally and I see what you
mean.

> The changes to defaultroute to wait for a default route to be set mean
> that you consolidate the wait in one location and you don't waste time
> starting dhclient on interfaces until a link exists (or an association
> is made for wlan devices).

OK, so that means that it's not just waiting for the default route, but
it's also waiting for the link on any DHCP interfaces to come up as
well. That's what confused me. When it's plugged in my NIC's link is
always up by the time rc.d gets to the default route, so I didn't see
the point in waiting the extra 30sec when it wasn't plugged in. The
comments also seemed to imply that we should be checking whether the
link is up.

Anyways, given that synchronous dhclient re-introduces the same problem
I was trying to fix in the first place I'll just back the whole thing 
out until we can come up with a better fix. Do you mind if I change the 
timeout to 15sec. (instead of 30s)?

>  There may well be something better to wait
> or a need for a longer timeout in some environments.  It's also quite
> possible that we have an ordering problem and need to move some more
> things after defaultroute or move the checks to a different location.
> 
> -- Brooks

Cheers.
-- 
Mike Makonnen       | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc
mtm @ FreeBSD.Org   | AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
FreeBSD             | http://www.freebsd.org