Re: The rc.d mess strikes back

In <49B410E0.4030803_at_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