[ntp:questions] ntpd (4.2.2p1) stays "synchronized to LOCAL"

Richard B. Gilbert rgilbert88 at comcast.net
Tue Dec 5 02:45:28 UTC 2006


Jordan Russell wrote:

> My ntpd is no longer synchronizing with the servers specified in
> ntp.conf, and I'm having trouble figuring out why.
> 
> ntp.conf looks like this:
> 
> restrict default kod nomodify notrap nopeer noquery
> restrict -6 default kod nomodify notrap nopeer noquery
> restrict 127.0.0.1
> restrict -6 ::1
> restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
> server ntppub.tamu.edu
> server ntp1.cs.wisc.edu
> server ntp-2.cso.uiuc.edu
> server  127.127.1.0     # local clock
> fudge   127.127.1.0 stratum 10
> driftfile /var/lib/ntp/drift
> keys /etc/ntp/keys
> 
> After 58 minutes of uptime, "ntpq -p" shows:
> 
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  ntp3.tamu.edu   128.194.254.7    2 u  386 1024  377   25.258  25459.4
> 8473.45
>  caesar.cs.wisc. 128.105.201.11   2 u  383 1024  377   51.257  25474.1
> 8473.20
>  ntp-2.gw.uiuc.e 128.174.38.133   2 u  442 1024  377   56.901  16496.2
> 8492.19
> *LOCAL(0)        .LOCL.          10 l   49   64  377    0.000    0.000
>  0.001
> 
> /var/log/messages shows:
> 
> Dec  4 15:38:02 ntpdate[16513]: step time server 128.194.254.9 offset
> 14.354204 sec
> Dec  4 15:38:02 ntpd[16517]: ntpd 4.2.2p1 at 1.1570-o Fri Aug 18 13:04:14
> UTC 2006 (1)
> Dec  4 15:38:02 ntpd[16518]: precision = 1.000 usec
> Dec  4 15:38:02 ntpd[16518]: Listening on interface wildcard,
> 0.0.0.0#123 Disabled
> Dec  4 15:38:02 ntpd[16518]: Listening on interface lo, 127.0.0.1#123
> Enabled
> Dec  4 15:38:02 ntpd[16518]: Listening on interface eth0,
> 192.168.1.1#123 Enabled
> Dec  4 15:38:02 ntpd[16518]: Listening on interface eth1,
> 76.187.xx.xx#123 Enabled
> Dec  4 15:38:02 ntpd[16518]: kernel time sync status 0040
> Dec  4 15:38:02 ntpd[16518]: getaddrinfo: "::1" invalid host address,
> ignored
> Dec  4 15:38:02 ntpd[16518]: frequency initialized 72.808 PPM from
> /var/lib/ntp/drift
> Dec  4 15:41:17 ntpd[16518]: synchronized to LOCAL(0), stratum 10
> Dec  4 15:41:17 ntpd[16518]: kernel time sync enabled 0001
> 
> When ntpd is in this state, the clock loses roughly half a second every
> minute, or about 10 minutes after a day of uptime (!).

How badly does the clock drift if ntpd is not running?  If it's still 
ten minutes per day, you either have a severe hardware problem or a 
software problem that is causing your system to lose timer interrupts.

> 
> I'm not sure if it's relevant, but I first noticed this problem about a
> month ago around the time ntp was upgraded from 4.2.0a to 4.2.2p1 (as
> part of upgrading from Fedora Core 5 and Fedora Core 6). Prior to that,
> the system ran ntpd for years without any issues.
<snip>

Simplify!!!   If you don't NEED IP V6, don't mess with it!!!  Even if 
you NEED it, debugging should be easier if you can eliminate it temporarily.

At the time you took your ntpq "banner", your clock appears to have been 
off by something between sixteen and twenty-five seconds.   Worse, two 
of  your servers have opinions of what time it is that differ by about 
ten seconds; one or both are insane!!!

Can you add at least one more internet server?  Two more would be 
better.  A total of five servers allows you to reject two bad ones and 
still have a workable configuration.

I suspect that your O/S upgrade introduced some bugs.  It's hard to 
tell, from here, what or where they might be.   Both the O/S and the new 
version of ntpd are suspect at this point.

Another odd thing is that your poll interval seems locked at 1024 
seconds when, given the humongous offset, I'd expect to see polling at 
64 second intervals.  With a polling interval that large, it may take 
weeks to synchronize your clock.  Normally we expect to see 1024 second 
polling only when your clock is already very well synchronized.

You can eliminate the RedHat version of ntpd by downloading the source 
using the links at http://www.ntp.org/, and building from source.  If 
that works, your problem is solved.  If it doesn't work, I'd say that 
you have either an O/S problem or a hardware problem.

Good luck.




More information about the questions mailing list