ntpd couldn't resolve host name on system boot

Jeremy Chadwick freebsd at jdc.parodius.com
Tue Oct 25 01:03:29 UTC 2011

On Tue, Oct 25, 2011 at 12:36:56AM +0100, Steven Hartland wrote:
> ----- Original Message ----- From: "Jeremy Chadwick"
> <freebsd at jdc.parodius.com>
> >The problem is that the networking layer is not TRULY available by the
> >time ntpd starts.  This does have to do with NIC drivers, but the same
> >behaviour can be seen on all NICs, including excellent ones like em(4).
> This is generally caused by links to high end switches e.g. cisco which
> havent had their "server" ports configured with portfast or similar
> settings. This creates quite a delay once link establishes before traffic
> is passed and hence the issue.

Correct.  Folks using STP, RSTP, or LLDP are most likely to see this.
However, in our environment we have all of these turned off on our
ProCurve switches yet we still see a ~1 second period of time between
when the kernel says "em0 is up" vs. when actual packets flow.  My point
is that even in bare-bones environments (consumer switches, etc.) it's
likely that there will be a small period of time where layer 3 packets
aren't actually working yet, despite layer 1 and (a portion of) layer 2
being done.

> netwait is an excellent script which fixes this and other network dependency
> issues, something we use as standard on all our machines now :)

It's a hackish workaround for something that should be solved elsewhere,
but solving it elsewhere has already been discussed at length in the
past so I won't get into it here.  (Simple version: we really need
something like "svcs" for Solaris, or one of those service-wrapper
daemons that Linux and other OSes use.  But let's not discuss that here

netwait's "design model" is very specific given people's needs; the
original design worked fine on some machines (all of ours) but I started
getting reports of problems from people using vlan(4) and bge(4), etc...
so the way it works now is actually reliable for all current NICs and
"weirder" environments.

The one shortcoming of netwait is that it doesn't support waiting for
multiple NICs.  Some people have dual-homed environments where they
really would like to wait for both, say, em0 and em1, to come up and be
functional before any more scripts are started.  I left that as a
project for someone else, but it's something that should be added given
its importance.

| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |

More information about the freebsd-stable mailing list