Date: Sun, 8 Mar 2009 16:46:57 -0400 (EDT) From: Garrett Wollman <wollman@hergotha.csail.mit.edu> To: sam@freebsd.org Cc: , current@freebsd.org Subject: Re: The rc.d mess strikes back Message-ID: <200903082046.n28Kkvfn005494@hergotha.csail.mit.edu> In-Reply-To: <49B410E0.4030803@freebsd.org> References: <2fd864e0903020512i22b2c31fg487aaf37fed6398b@mail.gmail.com> <20090302.132522.-432836388.imp@bsdimp.com> <20090302233215.GA53763@duncan.reilly.home> <20090302.181513.1973603215.imp@bsdimp.com> <584bfc3f0903030833k70405609q7e2d3b28c8cf4c29@mail.gmail.com> <20090303180307.GA11134@lor.one-eyed-alien.net> <584bfc3f0903032212x25831c5bi35d9b637c1896e1d@mail.gmail.com> <7d6fde3d0903040004y1fcbb086i355cd0113717620b@mail.gmail.com> <20090304164953.GB1209@lor.one-eyed-alien.net> <49B397A4.8090508@gmail.com> <20090308180934.GA9147@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In <49B410E0.4030803@freebsd.org>, Sam Leffler writes: >wpa is typically not the issue unless wpa-eapol is involved (in which >case you need to negotiate with a backend authentication server). I hesitate to bring this up, but I've certainly had an issue for a long time that waiting for the default route doesn't solve -- the machines in question are configured statically. The problem is most pronounced with certain GigE interfaces that take a very long time to initialize, but happens on any network using the default Spanning Tree parameters. (Using DHCP would actually help with this, since you can't get a DHCP response until your port has moved into FORWARDING state, but one of the machines in question is the DHCP server, so that's not an option.) Because named no longer waits for a root server to be accessible when it starts, lots of daemons will get started, be unable to resolve names in their configuration files, and fail, before the network interface is even working. (ntpd is a particular problem in this case, because it doesn't exit when there are no associations configured, and it also does its name resolution asynchronously, so you can have ntpd come up and appear to be working, but completely unsynchronized.) I've generally solved this by hacking a little script into the order just after named to hold back the boot until named is able to resolve an external hostname. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903082046.n28Kkvfn005494>