| Paul L. Snyder on Tue, 11 Mar 2003 22:11:19 -0500 |
|
On Tue, 11 Mar 2003, gabriel rosenkoetter wrote:
> On Tue, Mar 11, 2003 at 07:13:47AM -0500, Arthur S. Alexion wrote:
> > On Tue, 2003-03-11 at 06:55, gabriel rosenkoetter wrote:
> > > On Tue, Mar 11, 2003 at 06:44:54AM -0500, Arthur S. Alexion wrote:
> > > > Any ideas?
[...]
> Note that ntpd is incapable of making a change of more than a couple
> of seconds. It's impossible for it to be the cause of a 12 hour
> clock skew. (If [x]ntpd(8) sees dates that far out from its time
> servers, it dies and logs a loud, angry message about it.)
Actually, there are a couple of switches you can supply to ntpd to force a
one-time massive clock change. If you issue an
ntp -qg
it will behave much like ntpdate. -q indicates ntpd should update the
time, then exit. -g allows a single shift of the clock beyond ntpd's sanity
limit (1000 seconds, by default). If running without -q, an attempt to
make a second such shift will cause ntpd to exit with an error.
> Also note that using rdate(8) is a bit of a blunt way to do things.
> Using ntpdate(8) is the preferred method, and under Red Hat populating
> /etc/ntp/step-tickers with ntp server IP addresses, one per line,
> will cause the xntpd init script to synchronize the time with
> ntpdate(8) (which permits massive skew) and then immediately start
> ntpd(8) to keep things in sync.
According to the ntpdate docs, this is actually deprecated, as well.
ntpdate is due to be removed from the ntp distribution - the new preferred
method is to use the ntpd options, mentioned above.
pls
Attachment:
pgpfUxAPV41Eu.pgp
|
|