NTP Problem
ntp always worked perfectly until I installed 14.1 two weeks ago, but does nothing now.
First error noticed was in /var/log/syslog - format error frequency file /etc/ntp/drift so I deleted the drift file; no more error, but no change. I check time against WWV with my shortwave radio, and can see the computer is 8 seconds fast. It was 10 fast last night. Can see in gkrellm that the response from timeservers is not happening. Tried replacing the two restrict lines with restrict from 14.0; no change. This what I tried so far: bash-4.2$ su Password: bash-4.2# /etc/rc.d/rc.ntpd stop Stopping NTP daemon... bash-4.2# ntpdate pool.ntp.org 29 Apr 09:36:53 ntpdate[1397]: no server suitable for synchronization found bash-4.2# ping -c5 0.ca.pool.ntp.org PING 0.ca.pool.ntp.org (192.75.12.11) 56(84) bytes of data. 64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=1 ttl=53 time=720 ms 64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=2 ttl=53 time=691 ms 64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=3 ttl=53 time=651 ms 64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=4 ttl=53 time=651 ms 64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=5 ttl=53 time=648 ms --- 0.ca.pool.ntp.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4549ms rtt min/avg/max/mdev = 648.587/672.586/720.075/28.536 ms bash-4.2# /etc/rc.d/rc.ntpd start Starting NTP daemon: /usr/sbin/ntpd -g Saving system time to the hardware clock (localtime). bash-4.2# ps -ef | fgrep ntpd root 2743 1 0 10:16 ? 00:00:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid bash-4.2# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 16 64 37 0.000 0.000 0.000 ns1.ptpbroadban .INIT. 16 u - 64 0 0.000 0.000 0.000 ntp.lanets.ca .INIT. 16 u - 64 0 0.000 0.000 0.000 euro-shared.oln .INIT. 16 u - 64 0 0.000 0.000 0.000 zero.gotroot.ca .INIT. 16 u - 64 0 0.000 0.000 0.000 bash-4.2# ls -l /etc/localtime-copied-from lrwxrwxrwx 1 root root 36 Apr 28 02:03 /etc/localtime-copied-from -> /usr/share/zoneinfo/America/Montreal bash-4.2# Here is my /etc/ntp.conf # Sample /etc/ntp.conf: Configuration file for ntpd. # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 server 0.ca.pool.ntp.org server 1.ca.pool.ntp.org server 2.ca.pool.ntp.org server 3.ca.pool.ntp.org # # NTP server (list one or more) to synchronize with: #server pool.ntp.org iburst # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /etc/ntp/drift # # Uncomment to use a multicast NTP server on the local subnet: #multicastclient 224.0.1.1 # listen on default 224.0.1.1 # Set an optional compensation for broadcast packet delay: #broadcastdelay 0.008 # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. # #keys /etc/ntp/keys #trustedkey 65535 #requestkey 65535 #controlkey 65535 # # Don't serve time or stats to anyone else by default (more secure) restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery # # Disable the ntpdc -c monlist command, which is insecure and can be used # to cause a denial of service attack (CVE-2013-5211). Future versions of # NTP will remove this command. disable monitor # # Trust ourselves. :-) restrict 127.0.0.1 restrict ::1 I did slackpkg reinstall ntp twice. No joy. Please advise. |
Comment out the 127.127.1.0 server and fudge lines. From experience, I've found using the undisciplined local clock reference causes problems with the initial 'large' adjustment ntpd does on startup. Instead, add:
Code:
tos orphan 10 # Assume the guise of a stratum 10 server when there BTW, ntp and hwclock in 'localtime' are never a good mix. I'd recommend running your hardware clock on UTC if you're planning on using ntp. |
Second GaxL's advice about the hardware clock running UTC. You will need to, as root, execute timeconfig and answer the questions after you have set the hardware clock to correct UTC time (which, if you're on DST, is local time + 4 hours).
One question, though, do you have DNS server addresses in /etc/resolv.conf or are you counting on wireless or wi-fi or a DNS server in your router? The lines above, Code:
bash-4.2# ntpdate pool.ntp.org About /etc/ntp/drift. You can poke a floating point number into that file to give the NTP daemon a place to start (NTP will update that value over time); as root, try Code:
echo 0.0 > /etc/ntp/drift Code:
<introductory text above here> Those local clock lines are for when your Internet connection drops, NPT will synchronize to itself (the system clock) until the Internet connection comes back. Essentially, you take the stock /etc/ntp.conf file, comment out Code:
#server pool.ntp.org iburst Things you want to do are
Code:
ntpq -pn Wait about 5-10 minutes and Code:
ntpq -pn By the way, using ntpq -pn avoids DNS look up for servers; it just displays faster. ;) You might want to check and see that you have the current stable NTP package installed: Code:
ls /var/log/packagers/ntp* Hope this helps some. |
Quote:
First with the 127.127.1.0 local reference enabled: Code:
root@ws1:~# date Code:
root@ws1:~# pkill ntpd I think I came to the conclusion that it was only ever using the local clock reference for the initial 'large' adjustment, which was always offset +0.0000, and so never adjusted local system time, and from that point onward the times it got from the ntp servers were too far adrift of local system time to be considered valid. The workaround, if you want to leave the local clock reference in your config file, is to always ensure you do a ntpdate prior to starting ntpd, so that the servers are within a reasonable offset when ntpd starts. Anyway, that's why I now recommend removing the local clock reference these days, though if your clock is always reasonably in-sync you're never likely to see this behaviour anyway. |
If in doubt, lose the restrict lines and add things back once you get time service back. Also, be sure that port 123/udp hasn't been firewalled off.
Really, though, the others here are correct. FWIW, the LOCAL clock is supposed to be deprecated in favor of ntpd's orphan facility. You do have a shortwave radio, though. Have you thought of using it with the CHU audio (127.127.7.x) or WWV audio (127.127.36.x) drivers? If you can get one of them going, you can have good time while working out the rest of the issues. Should you need to recompile ntpd in order to use them, I think the ./configure flags will include "--enable-WWV --enable-CHU --enable-AUDIO-CHU". You can add them directly to the ntp.SlackBuild file that comes with Slackware's ntpd source code. If you remove the NTP drift file altogether, it will take longer for ntpd to figure out the drift rate and therefore write the drift file. All of those .INIT. flags in your ntpq output makes me think that the issue is something else, though. Either that or you didn't let things ntpd for long enough... There are more things to check, but this seems like a good start. |
The only problem with the examples is how the NTP daemon gets started in the first place and how it keeps things synchronized.
The hardware clock, set to within 1,000 seconds of UTC, is read at boot and initializes the software (system) clock. If you're not withing 16 minutes, it ain't gonna synchronize, come hell or high water. It's easy enough, if it doesn't synchronize within about 5- 10 minutes of run, to stop the daemon and use ntpdate (or, better, ntpd -g -q) to set the system clock to local time, then restart NTP (and it should then synchronize with an external server). At system shutdown, the synchronized time is written to the hardware clock. All that works if the CMOS battery isn't dead (or you're just rebooting). Dead CMOS battery, well, same thing happens if your electric wristwatch battery dies (and you can be off by days depending upon how long the system has been turned off and you really don't want that to happen). The -g argument to ntpd will allow the time to be set to any value without restriction, so Bad Things Can Happen if the CMOS battery is dead (imagine all your time stamps being set to five days ago, for example). Generally, it's not a good idea to delete /etc/ntp/drift, which contains the pfudge pfactor that's used to "walk" the the system clock into synchronization. On a newly installed system I always punch 0.0 into that file rather than waiting for the NTP daemon to write to it after some, fairly long, period of synchronized time. Too, ntpdate is considered obsolete; ntpd -g -q server should be used instead to initialize the system clock to the correct time (ntpd sets the time and quits). The -x option can be used in conjunction with the -q option, but: Quote:
The timeconfig utility should be used to define the hardware clock as UTC and set the system location (country, region). The Powers that Be seem to have decided that hardware clocks should be UTC (and, frankly, that's a good idea in any event); keep in mind that when the system is rebooted or shut down that the synchronized time from the system clock is written to the hardware clock, then read back from the hardware clock to set the system clock on boot. Hardware clocks are, any more, fairly accurate. System clocks are notorious for drifting all over the place without something (like NTP) keeping them on time (within milliseconds after NTP has been running for a few days or weeks). I remember a couple of boxes that drifted about 10 minutes every 4 hours before I installed NTP to bring them into synchronization (that took days because of the kernel tweaks that NTP does). Other than buying a (expensive!) GPS or radio clock, NTP is the best bet for Pretty Good Timekeeping. I serve all the components that have NTP compatible clocks from one server on my LAN and have done so since, cripes, the mid- to late 1980s or so (them were the days). Can't recommend it highly enough. Hope this helps some. |
Quote:
So, it seems you either need to maintain an alternative config file without either of those options enabled specifically for use with something like ntpd -q -g -c /etc/ntp-quit.conf, or stick with the deprecated 'ntpdate', or alternatively use 'sntp -s <server>' instead. Each approach likely has its pros and cons. Well, I think that's about exhausted my knowledge on ntpd. ;) |
I substituted tos orphan 10 for the fudges, commented out 3 of the restrict lines leaving only restrict 127.0.0.1 and will wait and see what happens.
|
Commenting out lines did no good at all.
Tronayne, content of /etc/resolv.conf is # Generated by dhcpcd from eth0 # /etc/resolv.conf.head can replace this line nameserver 192.168.175.250 nameserver 192.168.175.251 # /etc/resolv.conf.tail can replace this line Then: # ntpdate 0.ca.pool.ntp.org 29 Apr 23:38:22 ntpdate[13055]: no server suitable for synchronization found and # ls /var/log/packages/ntp* /var/log/packages/ntp-4.2.6p5-i486-5_slack14.1 I'm thinking that ntp always worked before 14.1, I always did the servers and driftfile and commented out the fudge, as others, and nobody else complains. So I intend to reinstall 14.1 from a different DVD. |
Have you made sure you've upgraded the ntp? There was one for it a little earlier this year IIRR. I can't remember if it was for security reasons or otherwise though. ftp://ftp.slackware.com/pub/slackwar..._slack14.1.txz
As for using ntp, I've never had any problems myself (unless of course I'm simply and completely not understanding what's going on here, which would not be beyond believable, heh). I have *always* used local time since the gmt thing only confuses me or I forget that I'm on it and think I've screwed something up by seeing the time and date and it's not really 'local' time. As root (su -) I just do: Code:
sntp -s north-america.pool.ntp.org |
Quote:
I'm easily confused sometimes! |
I didn't misunderstand your meaning tronayne, what I meant was ntpd complains when you try and specify a server on the command line like that:
Code:
root@ws1:~# ntpd -q -g uk.pool.ntp.org |
You could reduce your ntp.conf to this...
Code:
pool ca.pool.ntp.org |
This was accidental double-posted.
|
Quote:
Code:
<comment lines above here> This is the default /etc/ntp.conf file delivered with ntp-4.2.6p5, the current stable version from Slackware stable: Code:
# Sample /etc/ntp.conf: Configuration file for ntpd. Code:
# I would suggest that you
Wait five- to ten minutes and execute ntpq again and you should see something similar to Code:
/usr/sbin/ntpq -pn You may want to check that your system is configured so that the hardware clock is set to UTC: Code:
fgrep UTC /etc/* 2>/dev/null Kernel developers and NTP developers appear to want your hardware clock on UTC; personally, I think that's probably for the best. Others prefer both the hardware and software clocks to use local time. That really should not be a problem, but it might sometime in the future. Either way, NTP will synchronize time for you. One other thing: if you execute ntpdate when the NTP daemon is running, you get Code:
ntpdate Code:
ps -ef | grep ntp Code:
kill -9 540 Hope this helps some. |
All times are GMT -5. The time now is 04:25 AM. |