ntpd fails on boot

Jeremy Chadwick freebsd at jdc.parodius.com
Wed Dec 15 01:12:51 UTC 2010

On Tue, Dec 14, 2010 at 06:55:22PM -0600, Zhihao Yuan wrote:
> ping is slow. I hope that we can change the behavior of detecting network to
> something event driven. Like to insert a script into syslogd to detect the
> host's dhclient status (in a static IP environment, we don't need
> 'netwait'), or check ifconfig, something like that.
> On Tue, Dec 14, 2010 at 6:47 PM, Jeremy Chadwick
> <freebsd at jdc.parodius.com>wrote:
> > On Tue, Dec 14, 2010 at 05:38:49PM -0700, Dan Allen wrote:
> > > Recently my network connection now is setup AFTER ntpd is launched rather
> > than before.
> > >
> > > So when ntpd starts there is no net connection and it gives up.
> > >
> > > I read /usr/src/UPDATING but nothing is mentioned about a change in boot
> > order.
> > >
> > > Any ideas?
> >
> > This issue has been discussed pretty thoroughly in the past.  There's no
> > official solution, but there is an rc.d script I wrote which addresses
> > this shortcoming.  Nothing related to the "boot order" has changed, but
> > network drivers and overall methodology has changed.
> >
> > Anyway, many people are using the below with success.
> >
> > http://jdc.parodius.com/freebsd/netwait
> >
> > Official patches, including the rc.conf(5) change I propose:
> >
> > http://jdc.parodius.com/freebsd/netwait_patches/
> >
> > Example usage (in rc.conf):
> >
> > netwait_enable="yes"
> > netwait_ip=""
> > netwait_if="em0"
> >
> > For what these variables mean, please see the script itself.  They are
> > thoroughly documented.

I don't know what "ping is slow" means -- utter nonsense.  Read the
script.  Look at how it works please.  Seriously.  I spent a lot of time
on it, with the help of a lot of community members (including some with
very complex network setups (multiple NICs of different brands, VLANs,
custom routes)).

netwait is in no way a permanent solution -- it simply addresses most
non-complex environments *reliably*.  ifconfig, devd, etc. are not
sufficient ways of determining if the network is *actually usable*.  I
cannot stress this enough.  I am not talking out of my ass.

What everyone's proposing (launchd, "way to monitor syslog",
event-driven, blah blah) is wonderful, but until someone has actually
done it, it's just ideal talk.  These words are coming from someone
who's very much an idealist, so keep that in mind too; I'm one of the
"worst offenders" when it comes to recommending solutions but not having
the time to implement them.

I'm going to bow out of the conversation at this point and simply ask
folks here on the thread to take the time to dig up/read old mailing
list archives on the matter.  We (FreeBSD Community and the freebsd-rc
folks) have been over all of this before.

Sorry for sounding crass and rude, but every time this question comes
up, I feel like I have to "defend" why the netwait script exists, why it
was designed the way it was, and so on.  Yes, a better infrastructure is
needed to solve the problem *at the core*, but until someone writes
that, we need something that works.

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

More information about the freebsd-stable mailing list