ntpd fails on boot

[Zhihao Yuan]

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


-- 
Zhihao Yuan
The best way to predict the future is to invent it.