ntp dies after a while....

[nse]

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 ??

kind regards

nse

"Ach, crivens, what a wee snotter....."

Quote from "The Wee Free Men" by Terry Pratchett


--
To UNSUBSCRIBE, email to debian-powerpc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rick Thomas]

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


--
To UNSUBSCRIBE, email to debian-powerpc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[nse]

Hi Rick

Den 30/09/2009 kl. 22.51 skrev Rick Thomas:

>
> 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.

ok.... so it's a "design feature" ... no big deal... I'll probably  
stick with the "-g" option then.....
It's running on a 400Mhz Tibook ... so it is low-powered....
and although "ntpdate" is run on boot.... the Tibook still loses some  
10-13 seconds in between "ntpd" wakes up....

> Sep 30 23:04:57 munin ntpd[22827]: synchronized to 85.27.152.130,  
> stratum 3
> Sep 30 23:04:57 munin ntpd[22827]: time reset +13.062046 s
> Sep 30 23:04:57 munin ntpd[22827]: kernel time sync status change 4001
> Sep 30 23:05:25 munin ntpd[22827]: synchronized to 90.184.109.31,  
> stratum 1
> Sep 30 23:05:28 munin ntpd[22827]: no servers reachable
> Sep 30 23:05:35 munin ntpd[22827]: synchronized to 85.27.152.130,  
> stratum 3
>

>
> For details, see "man ntpd"
>
>
> Rick

kind regards

nse

"Ach, crivens, what a wee snotter....."

Quote from "The Wee Free Men" by Terry Pratchett


--
To UNSUBSCRIBE, email to debian-powerpc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rick Thomas]

On Sep 30, 2009, at 5:22 PM, Niels S. Eliasen wrote:

>> 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?
>>

> ok.... so it's a "design feature" ... no big deal... I'll probably  
> stick with the "-g" option then.....
> It's running on a 400Mhz Tibook ... so it is low-powered....
> and although "ntpdate" is run on boot.... the Tibook still loses  
> some 10-13 seconds in between "ntpd" wakes up....

OK.  Now we know what's causing it.  When your laptop goes into low-
power mode, the clock runs at an incorrect rate.  When it comes back  
to full-power mode, the clock isn't getting synced.

Maybe there's a way to get control at entering and exiting sleep  
mode.  I don't know -- never felt the need for a Linux based laptop.  
If so (anybody out there know?) you could put in an ntpdate call then.

Or maybe if you read the ntpd man page carefully -- there may be a  
back-door way to get the ntpd "sanity window" set *very* wide.  It's  
worth a try.

Rick


--
To UNSUBSCRIBE, email to debian-powerpc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...