On 11/05/12 13:24, steve-ALUG@hst.me.uk wrote:
Is there anything else in the log that's getting a signal 15 at the same time as ntp dying?
Nothing else in the logs around that time, other than cron (which you'll recall was where I started).
Looking at them now (at about 2:02pm): - hwclock reports the time as 13:02:35 UTC (correct) - date reports the time as 13:16:46 UTC (~15 mins out).
syslog reports ("Listen" lines stripped for clarity) the following: note clock goes from 12:46 to 12:43 (and that was presumably after 15 minutes), 12:43 to 13:05 (seems reasonable after ~15 minutes), 13:05 to 12:57 (backwards again).
May 11 12:46:57 debian ntpd[3728]: ntpd 4.2.6p5@1.2349 Mon Feb 27 12:39:16 UTC 2012 (1) May 11 12:46:57 debian ntpd[3729]: proto: precision = 1.440 usec May 11 12:46:57 debian ntpd[3729]: peers refreshed May 11 12:46:57 debian ntpd[3729]: Listening on routing socket on fd #25 for interface updates May 11 12:43:05 debian ntpd[3729]: ntpd exiting on signal 15
May 11 12:43:07 debian ntpd[3872]: ntpd 4.2.6p5@1.2349 Mon Feb 27 12:39:16 UTC 2012 (1) May 11 12:43:07 debian ntpd[3873]: proto: precision = 1.445 usec May 11 12:43:08 debian ntpd[3873]: peers refreshed May 11 12:43:08 debian ntpd[3873]: Listening on routing socket on fd #25 for interface updates May 11 13:05:26 debian ntpd[3873]: ntpd exiting on signal 15
May 11 13:05:29 debian ntpd[3986]: ntpd 4.2.6p5@1.2349 Mon Feb 27 12:39:16 UTC 2012 (1) May 11 13:05:29 debian ntpd[3987]: proto: precision = 1.445 usec May 11 13:05:29 debian ntpd[3987]: peers refreshed May 11 13:05:29 debian ntpd[3987]: Listening on routing socket on fd #25 for interface updates May 11 12:57:39 debian ntpd[3987]: ntpd exiting on signal 15
May 11 12:57:41 debian ntpd[4093]: ntpd 4.2.6p5@1.2349 Mon Feb 27 12:39:16 UTC 2012 (1) May 11 12:57:41 debian ntpd[4094]: proto: precision = 1.440 usec May 11 12:57:41 debian ntpd[4094]: peers refreshed May 11 12:57:41 debian ntpd[4094]: Listening on routing socket on fd #25 for interface updates
The time jumping backwards, I would guess is because NTP *is* adjusting the clock, but, if NTP is running correctly, I'd have thought it would adjust the clock gradually, having noted the drift between the h/w clock and the internet time servers, rather than jumping.
But also, shouldn't it be adding something to the log to say it's changed the clock?
Ideas: log ntp to a separate log file. Increase the debug-log level.
I couldn't see how to do this?
Investigate ntpq -p as per http://perdues.com/doc/ntp.html
$ ntpq -p remote refid st t when poll reach delay offset jitter ======================================== +46-38-164-94.st 83.138.151.80 4 u 22 64 37 29.882 8.223 30.137 *85.12.35.12 193.79.237.14 2 u 15 64 77 36.732 7.545 63.424
The figures don't look great from my reading of the above page, but not bad either.
Notable is the comment on that page that regarding syslog that: "If your local server steps the time ahead or back suddenly, it will report that here also with a message such as: time reset -6.394626 s." I am not seeing anything like this logged.
Any of this help? http://linux.die.net/man/8/ntpd
Not really, or at least if there's something helpful there I'm missing it.
I have a nagging feeling that this nothing to do with ntp. I've just killed ntp to see what happens to the clock in its absence.
Thanks for the help!
Mark