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_at_ 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:43 UTC