looks fine -- one thing you might want to change, though, is add or edit this to allow multicasting (it's not absolutely necessary but may help):
Then you should see lines like this every so often in your log:
22 Jan 14:37:41 ntpd: Listen normally on 5 multicast 22.214.171.124 UDP 123
22 Jan 14:37:52 ntpd: Listen normally on 6 eth0 fe80::210:18ff:fe8a:82c1 UDP 123
Check your /etc/ntp/drift
file; there should be a number in it, something like
Yours, of course, will vary. If that file does not
exist, you will need to create it with a zero in it (if it does exist, don't do this but do see what the value is, it's a text file, you can simply cat
cat > drift
Looking at your log entries, it does not appear that NTP ever synchronized. When it has synchronized, the output of ntpq -pn
will look like
remote refid st t when poll reach delay offset jitter
127.127.1.0 .LOCL. 10 l 88 64 76 0.000 0.000 0.002
*126.96.36.199 188.8.131.52 2 u 7 64 77 1260.51 21.718 62.851
+184.108.40.206 220.127.116.11 2 u 7 64 77 1501.47 51.393 12.867
+18.104.22.168 22.214.171.124 2 u 5 64 77 1601.49 144.431 88.870
The asterisk and plus signs must
appear or you're not synchronized. Before you do anything else, do this:
Is the result within a minute or so of the actual time? If so, do this
# stop the server
# start the server
# wait about five minutes and execute
# exit from su
If not, that usually means that the clock was too far off for NTP to sync it and the fix is
# first, stop the server
# use ntpdate to set the clock
# start the server
# wait about five minutes and exeucte
Now, the use of ntpdate
above is going to slew the clock to the correct time.
If your system was rebooted at some point (it looks as if it was given the log entry)
22 Jan 03:20:47 ntpd: ntpd exiting on signal 15
Were you really fiddling with it in the middle of the night? Wow.
Anyway, what happens when you shut the system down is that the system clock time is written to the hardware clock, which is kept running by a small battery on the motherboard. When the system is booted, that time is read from the hardware clock and the system clock is set to that time. The system clock is not an actual "clock;" it's timer executed by the kernel. The hardware clock is an actual clock chip (something like the ones in a wristwatch) that is kept running by the battery (system time is independent of the hardware clock after the system boots).
You've said that you were running Slackware 12? On the same hardware? It's quite possible that you've got a dead battery (Slackware 12 goes back a few years). If that's the case, the hardware clock isn't keeping time and, when the system boots, the system clock gets set to some who-knows-what time. You can tell if this is a problem by running date
, write that down, reboot but enter the BIOS instead of letting the system boot.
Check the hardware clock time in the BIOS and compare the time to what the date
utility showed you.
Hope this helps some.