On 05/13/2004 10:17:37 AM, Corné Beerse wrote:
Steve Blackwell wrote:
Last weekend, a lightning stike knocked out a switch which was connecting my ntp server. As a result my ntp server's time is off by about 3 days.
After rebooting the switch and the server, the server will not set the correct time. I'm using the -g option to ntpd.
Most systems start with the time found in the bios.
Then ntp only updates the time if it is within reasonable limits (couple of minutes or up to an hour).
The way I understand it is that if you use the -g option when ntpd is started, asI have done, it does a one time update of the clock regardless of the time difference. But in my case, it seems that the -g flag was ignored. I am curious as to why. Here is the section of the ntpd man page for the -g option:
-g Normally, ntpd exits if the offset exceeds the sanity limit,
which is 1000 s by default. If the sanity limit is set to zero, no sanity checking is performed and any offset is acceptable.
This option overrides the limit and allows the time to be set to any value without restriction; however, this can happen only
once. After that, ntpd will exit if the limit is exceeded.
This option can be used with the -q option.
The other strange thing is that since I am off by >1000s, why hasn't ntpd exited?
In short, the -g option removes the sanity limit once. Now ntpd tries to correct the time even if it is way out of sync. ntpd by default does not set the new time but it slows or speeds the clock to get in sync. This is up to a couple of miliseconds per second. Hence 1 or 2 minutes per hour.
You should read the last line about the -p option as a hint: That realy sets the time.
Most configurations start with an `ntpdate` followed by `ntpd`. Current implementations can do so at once with `ntpd -p -g`.
CBee
Steve.
