Re: ntp dies after a while....
On Sep 30, 2009, at 4:15 AM, Niels S. Eliasen wrote:
hi guys
Noticed that after some days(even weeks) ntpd dies for no apparent
reason......
Anyone seen this ?
and are there any known fixes ?
from daemon.log I see:
Sep 28 12:49:59 munin ntpd[19926]: synchronized to 93.163.47.122,
stratum 2
Sep 28 12:49:59 munin ntpd[19926]: time correction of 2295 seconds
exceeds sanity limit (1000); set clock manually to the correct UTC
time.
but as the daemon is running... surely it should correct this before
getting into this "exceeds sanity limit" issue ??
I don't know how the system clock gets so far off from UTC -- maybe
indicative of a hardware problem? Are you, maybe, using anything
besides NTP to set your clock? Maybe one of your servers
(93.163.47.122 springs to mind) is serving bogus time?
In any case, the "step the clock if necessary -- no matter how far off
it may be" ( "-g" option to ntpd) mode is a one-shot to take care of
machines that have lousy (or non-existent) on-board CMOS clocks. They
come up after a reboot with very-wrong or simply random time. After
the time is judged to be in sync, ntp refuses to step the clock if
it's discovered to be outside of the sanity window.
The logic of this policy is that if the clock is synced, and it
suddenly goes out of sync, there is something terribly wrong, and the
sysadmin needs to get it fixed. Silently stepping the clock by more
than 1000 seconds is not the right thing to do. It could cause much
more harm than good. So the ntpd daemon commits suicide rather than
contribute to a larger problem.
This has been discussed endlessly on the NTP mailing lists. It's a
decision made by Dave Mills himself, and he refuses to change his mind.
For details, see "man ntpd"
Rick
Reply to: