ntpdate on boot problem

krad kraduk at gmail.com
Mon Nov 7 09:20:33 UTC 2011

On 6 November 2011 02:51, Robert Simmons <rsimmons0 at gmail.com> wrote:

> On Sat, Nov 5, 2011 at 7:43 PM, Warren Block <wblock at wonkity.com> wrote:
> > netwait_enable="YES"
> > netwait_ip="" # IP address to ping to verify network is up
> > netwait_if="em0" # interface to use
> >
> >
> > Also there's netwait_timeout, which defaults to 60 in
> /etc/defaults/rc.conf.
> I've finally got a combination of suggested configurations that get me
> to where I want to be (using ntpd, ntpdate, and netwait).
> However, I've found that I still need ntpdate_enable="YES" rather than
> ntpd_sync_on_start="YES".  The reason for this is that I'm running at
> securelevel 3, and ntpd takes too long to get up, running, and sync
> the clock.  By the time it tries to adjust the clock, secure level has
> already been raised preventing the adjustment.
> Is there a way to make securelevel wait until ntpd has made its
> adjustments?  When I use ntpdate at this point, it seems like the init
> scripts are sequential, and it waits until ntpdate is done before
> continuing and later raising securelevel.
> It seems that even though ntpdate is deprecated that it is still
> required if you want to run securelevel 3.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"

Another thing you may want to look at is your switchport config (assuming
its managed), if you are running STP it can take upto a minute for the port
to go into forwarding state after the line is up. You can do two things to
get around this.

1. use rstp instead - this is the better safer way forward. However you may
not have control of the network and could be a big thing to do depending on
your organization.
2. enable portfast on the relevant switches. This is potentially dangerous
as it disables stp and therefore potentially exposes you to switching
loops. However if the port is only ever plugged into on machine and EU dont
play with the cables shold be fine

More information about the freebsd-questions mailing list