The rc.d mess strikes back

[Brooks Davis]

On Tue, Mar 03, 2009 at 07:33:39PM +0300, Mike Telahun Makonnen wrote:
> On Tue, Mar 3, 2009 at 4:15 AM, M. Warner Losh <imp at bsdimp.com> wrote:
> > In message: <20090302233215.GA53763 at duncan.reilly.home>
> > ? ? ? ? ? ?Andrew Reilly <andrew-freebsd at areilly.bpc-users.org> writes:
> > : On Mon, Mar 02, 2009 at 01:25:22PM -0700, M. Warner Losh wrote:
> > : > In message: <2fd864e0903020512i22b2c31fg487aaf37fed6398b at mail.gmail.com>
> > : > ? ? ? ? ? ? Astrodog <astrodog at gmail.com> writes:
> > : > : As unfortunate (and annoying) as that delay was, your system was in a
> > : > : "defined" state, at the end of rc.d. As things stand now, that doesn't
> > : > : appear to be the case anymore, and I think that may be a more
> > : > : significant issue than the delay.
> > : >
> > : > I'd be happy with synchronous dhcp.
> 
> Ok. I've been waiting to see if brooks@ was going to weigh in on this,
> but I'll go ahead and make the change now and see if there is any more
> fall-out. Once that's done, network behaviour should be more or less
> the same as before my change, with the exception that any DHCP
> interfaces that aren't plugged in may delay the boot by more than
> 30sec.

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.

BTW, the change to background by default still doesn't make sense to
me.  At best it shouldn't do anything useful in the async case and it
entierly defeats the sync case.

> [snip]
> >
> > : Needing synchronous DHCP as a work-around here is just the
> > : signifier of the problem: it isn't the over-all solution.
> >
> > It is a short-term work-around at best.
> 
> >From the problems that have been reported so far it seems to me the
> problem is with some drivers that repeatedly bring the network link up
> and down.  The *ideal* solution seems (to me) to be to fix these
> drivers.  Am I wrong?

This needs to be the solution in the end.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20090303/fa159bb9/attachment.pgp