NTP issue - time drifting, ntpd crashing?
in [Slackware]
|
Prev: Driver for Buffalo LPC PCM CLX
Next: Apple iPod
From: Grant on 19 Jan 2006 06:14 On Thu, 19 Jan 2006 21:08:52 +1100, Logical <me(a)privacy.net> wrote: >The time is now about four minutes off > ># ntpq -p > remote refid st t when poll reach delay offset >jitter >============================================================================== >*LOCAL(0) LOCAL(0) 10 l 5 64 377 0.000 0.000 Lose the local fallback stanza, RTFM. recipe killall ntpd ntpdate <server_ip> ntpd wait . . . . . . . ntpq -pn If all else fails RTFM!! This aint rocket science ;) Cheers, Grant. -- WinXP: Access Start->Turn Off Computer, then while holding Ctrl-Alt-Shift, left click on Cancel. This kills Windows Explorer.
From: Thomas Ronayne on 19 Jan 2006 07:09
Logical wrote: > > I figured that was one of my problems, I've now got (for testing > purposes) no restrict statemtnts which should allow all time sources > to be used. > > I now have better performance, but only for two days. The log file has > entries for two days, then nothing. > > # tail /var/log/ntp.log > 16 Jan 12:15:10 ntpd[2810]: time reset +0.173450 s > 16 Jan 12:19:28 ntpd[2810]: synchronized to LOCAL(0), stratum=10 > 16 Jan 12:23:46 ntpd[2810]: synchronized to 203.0.178.191, stratum=3 > 16 Jan 12:24:48 ntpd[2810]: synchronized to 128.184.1.1, stratum=2 > 16 Jan 17:34:08 ntpd[2810]: synchronized to LOCAL(0), stratum=10 That looks like your (or somebody else's) internet connection is dropping -- when you lose the internet, NTP syncs to LOCAL until an external source comes back -- or your clock is so far off that NTP can't keep it synchronized. The top of your log file should look a lot like this: 18 Jan 16:56:53 ntpd[5188]: logging to file /tmp/ntp.log 18 Jan 16:56:53 ntpd[5188]: ntpd 4.2.0(a)1.1161-r Mon Mar 29 22:23:49 PST 2004 (1) 18 Jan 16:56:53 ntpd[5188]: precision = 1.000 usec 18 Jan 16:56:53 ntpd[5188]: kernel time sync status 0040 18 Jan 16:56:57 ntpd[5188]: frequency initialized -94.475 PPM from /etc/ntp/drift 18 Jan 17:00:11 ntpd[5188]: synchronized to LOCAL(0), stratum=10 18 Jan 17:00:11 ntpd[5188]: kernel time sync disabled 0041 18 Jan 17:01:16 ntpd[5188]: kernel time sync enabled 0001 18 Jan 17:05:32 ntpd[5188]: synchronized to 216.165.129.244, stratum=1 18 Jan 17:41:48 ntpd[5188]: time reset +0.177636 s 18 Jan 17:46:06 ntpd[5188]: synchronized to LOCAL(0), stratum=10 18 Jan 17:47:10 ntpd[5188]: synchronized to 216.165.129.244, stratum=1 The log file, with a permanent connection (like DSL, cable, T1, whatever), will only have a few entries in it. If there are a lot of LOCAL entries, which means NTP can't contact any of the servers listed in your ntp.conf file, you need to spend some time looking for two or three servers that are more reliable. Try using ping and traceroute to servers and pick ones with the best ping response and the shortest path shown by traceroute. > > # date > Thu Jan 19 21:02:03 EST 2006 > > The time is now about four minutes off That's way too much. Does your motherboard have a battery for the clock chip and is it dead? Take a look at /etc/ntp/drift -- it should be a floating-point number, probably less that 100.0. If it's greater than that, try stopping ntpd, replacing the value with 0.0, start ntpd and then watch it for a couple of days. If that value gets large, you've got a real problem with the clock chip (possibly the battery if there is one) and you'll need to adjust it -- see adjtimex and hwclock, particularly adjtimex, noting that you might want to do the adjustments described in adjtimex (without NTP running). Given that date returns EST, I assume you're in the North American eastern time zone and if I remember correctly you're running Slackware 10.0? There were some problems with NTP in 10.0 (nothing major, just annoying). Try using these server entries and see what you get: server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org > > # ntpq -p > remote refid st t when poll reach delay offset > jitter > ============================================================================== > > *LOCAL(0) LOCAL(0) 10 l 5 64 377 0.000 0.000 > 0.001 > dns.iinet.net.a 203.55.231.26 3 u 858 1024 377 15.951 268580. > 1433.16 > fa0-0-1.syd-cor 202.72.191.202 3 u 891 1024 377 26.420 268526. > 1420.71 > sol.ccs.deakin. 128.250.36.2 2 u 797 1024 377 34.411 268668. > 1432.60 > 241.126.233.220 LOCAL(0) 11 u 775 1024 77 70.752 268291. > 1424.89 > > From that I ascertain that it can still contact the time server? Uh, no -- it's died and gone to the great byte bucket in the sky; offset should be in the range of 10-100 and jitter in the range of 0 (LOCAL) to, oh, up to about 40 or 50. > > ntpd appears to be still running correctly > # ps aux | grep ntpd > root 2810 0.0 0.7 3644 3640 ? SLs Jan15 0:05 > /usr/sbin/ntpd -l /var/log/ntp.log It's not doing anything. Try /etc/rc.d/rc.ntpd stop ntpdate /etc/rc.d/rc.ntpd start and watch the router or modem lights for a while; you'll see some blinking while NTP is trying to sync up with a server for a short time and then that activity will stop after less than a minute. If the lights keep flashing, you're not getting synchronized. > > Any other thoughts? Read through adjtimex and hwclock and do the adjustments described (if they're necessary), try the pool servers, try ping and traceroute. If you've been fiddling with ntp.conf a lot, it might not hurt to go back to square one -- reinstall the ntp package, add three pool servers without editing anything else and see what happens. -- Everything works -- if you let it. |