title: The edge of sanity: info on diagnosing ntpd problems link: https://onemoretech.wordpress.com/2008/10/14/the-edge-of-sanity-info-on-diagnosing-ntpd-problems/ author: lembobro description: post_id: 445 created: 2008/10/14 13:32:05 created_gmt: 2008/10/14 13:32:05 comment_status: open post_name: the-edge-of-sanity-info-on-diagnosing-ntpd-problems status: publish post_type: post

The edge of sanity: info on diagnosing ntpd problems

So we’ve been getting this cronic error in /var/log/messages, after which the ntpd daemon dies and only comes back after a manual restart (shut down first to clear the pid):

Oct 14 05:00:20 testserver1 ntpd[15982]: time correction of 1262 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

Because its a core service on the Internet, ntpd services are pretty well documented. In times of trouble I am most likely to turn to the ntpd home pages hosted by the University of Deleware.

The ntpd System Log Messages page opens with the following:

You have come here because you found a cryptic message in the system log… Most of the time LOG_ERR messages are fatal, but often ntpd limps onward in the hopes of discovering more errors.

Right off the bat you know that this is going to be some serious, detailed documentation.

As for the problem at hand, here’s the relevant entry in the doc, with some no-nonsense commentary:

LOG_ERR
time correction of ? seconds exceeds sanity limit (?); set clock manually to the correct UTC time.
Fatal error. Better do what it says, then restart the daemon. Be advised NTP and Unix know nothing about local time zones. The clock must be set to Coordinated Universal Time (UTC). Believe it; by international agreement abbreviations are in French and descriptions are in English.

So much for the brilliant idea of setting all system clocks to local (in my case Eastern Standard) time.

It’s really amazing how parochial even many techs (and their management) can be.

Thumbing your all-American nose at at international standards always leads to trouble — and in this particular case following them can save serious time and money. Just recall the last few years having to update time zone files because you continue to insist on running with local time?

Of course since they’ve been running things that way for a long time, there’s almost no hope that your apps have been written to handle timezone adjustments at the front end.

Hah!

Copyright 2004-2019 Phil Lembo