ntpd fails on boot

Wed Dec 15 02:03:02 UTC 2010

On Tue, Dec 14, 2010 at 07:43:04PM -0600, Zhihao Yuan wrote:
> I read your script. OK. My question is, how can I use more than 1
> netwait_if? I know I can just use netwait_ip instead, but, for example, in a
> mDNS configured environment, ping may take a long time to response. In some
> conditions, it can be 1min. So I don't want to use the fallback 'ping'
> method. Most laptops today have both LAN and WLAN internet faces, some of
> them have even more. So please give my 'utter nonsense' an answer.

> On Tue, Dec 14, 2010 at 7:12 PM, Jeremy Chadwick
> <freebsd at jdc.parodius.com>wrote:
> 
> > 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="4.2.2.1 4.2.2.2"
> > > > 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.

"ping is slow", literally, is nonsensical.  There's nothing "slow" about
ping.  You can adjust netwait_timeout as you see fit if you don't like
waiting for ICMP ECHO REPLY -- but I won't be held responsible if layer
1 or layer 2 takes longer than $netwait_timeout to be configured.

But now you're changing subject matter -- you have a dual-homed machine
that you want to verify the usability of both interfaces for.  Verifying
packet flow *actually works* on both of these interfaces is possible,
but the present incarnation of the script does not support this.

If your network interface takes 60 seconds to come up and get configured
fully, and Internet connectivity needs to be reliable before starting
daemons that rely on such connectivity, then you *absolutely should* be
waiting 60 seconds or longer.  It's up to you to decide whether or not
reliable network connectivity is work waiting for.

Why?

Because named, ntpd, and many other daemons do not "retry" if their
initial attempts to do DNS lookups or communication fail.  I'm not
responsible for this problem -- but netwait helps ensure that these
failures no longer happen -- which is what the OP was complaining about.

Circling back to "what interface do I choose": the design concept is
that you should pick whatever interface is, ideally, associated with
your default gateway (in theory, whatever points towards the Internet).

For example: if you have two NICs (LAN and WLAN), both of which are
connected + configured during network configuration time, and both go to
the Internet, then it really doesn't matter which interface you choose
in netwait_if.  If you rely more on the WLAN interface (e.g. physical
LAN might not always be connected depending on your environment), then
pick the WLAN interface and be done with it.

And all of this is assuming that you want to verify your *Internet*
connectivity works -- again, remember the OP's complaint.

Furthermore, nothing stops you from also using a netwait_ip of something
on your LAN (like 192.168.1.1 for your home router, etc.).

I can't really phrase any of this any better.  If you'd like to work on
the daemons that don't retry some of their network activity on startup,
please do so -- it would be a more proper fix.  But there are many such
daemons that behave this way.  The design model of these daemons is to
assume network connectivity is working when they start, and netwait
reliably ensures that.

-- 
| 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 |