[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
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.
More information about the questions