[ntp:questions] Fwd: Using ntpdate -b SERVER shortly after SERVER boots

Donald Murray, P.Eng. donaldm314 at gmail.com
Mon Feb 12 19:46:21 UTC 2007


Oops. Sorry for the off-list reply.

---------- Forwarded message ----------
From: Donald Murray, P.Eng. <donaldm314 at gmail.com>
Date: Feb 12, 2007 12:45 PM
Subject: Re: [ntp:questions] Using ntpdate -b SERVER shortly after SERVER boots
To: Steve Kostecke <kostecke at ntp.isc.org>


On 2/12/07, Steve Kostecke <kostecke at ntp.isc.org> wrote:
> "Donald Murray, P.Eng." said:
> >Yes, that's how we adjust the time.
>
> Great! You'd be surprised at how many people get that wrong.

Trying to be clueful here. I'm a big proponent of ntp, and long overdue
in joining this list.

> I don't call if I mentioned the ntpd '-g' option. The '-g' option allows
> ntpd to excedd the 1024 second sanity limit and make an unlimited
> initial step. If you can use '-g' with your version of ntpd you don't
> need ntpdate. If you want the initial time setting to block the system
> boot you'll need to invoke 'ntpd -gq'.

For our systems it's simpler to use the ntpdate/date approach than
start ntpd and wait for it to sync. We need to know when the clock
may be stepped, and insure our apps are not running.

> >- attempt 'ntpdate -b SERVER'
> >- if ntpdate fails, use a CGI
>
> <pedant>
>         s/CGI/script/
> </pedant>

It's a CGI on the SERVER, called by a script on the CLIENT.

> >to obtain the current date on SERVER; feed that to /bin/date
>
> And then start ntpd?

Yes, we then start ntpd.
>
> That sounds like a reasonable fall back.
>
> The real benefit to using NTP instead of rdate, etc al, is that ntpd
> will attempt to steer your clock to the correct time (by trimming the
> clock frequency) instead of just stepping it periodically. But you do
> have to do what ever works within your limitations.

Agreed. Glad I'm not the only one that thinks this is reasonable
given our unreasonable constraints.

Thanks again!



More information about the questions mailing list