NTP is running, system clock still not in time - what gives?
Solution 1
Stop ntpd, run ntpdate -u 0.europe.pool.ntp.org
3 times, start ntpd, check up on ntpq -p
, delay, offset and jitter should be non-zero.
Solution 2
The "reach" columns being 0 suggests it wasn't able to talk to the servers- iirc it gradually gets bits shifted in to show how the last 8 attempts went (so 377 is good, 0 is bad).
Solution 3
If I had to guess as to why and assuming you have network connectivity and can see your NTP Host without a problem then it could be you have drifted to a large value. If the time difference is greater than X (Sorry I dont remember what X is offhand) than a warning will be printed and time will not be syncd. You can check your syslog messages for cases of this.
If this is the case stop NTP, run ntpdate host and restart the NTPD this will force a time sync then start keeping it in sync going forward, if you continue to drift that much you may have a hardware issue.
Related videos on Youtube
geekyaleks
Java developer; more active on Stack Overflow and some of the newer SE sites. Linux user since 1998. Server administration isn't my main thing, but from time to time I do some of that too at work: Setting up & maintaining tools such as Jenkins, Mediawiki, Confluence, Subversion, GitLab, PostgreSQL and MySQL; mostly on Linux (Ubuntu, Debian, Red Hat or Fedora). Deployment of Java webapps, with e.g. Tomcat, Jetty, JBoss and Apache. Recently I've been learning about and using AWS as a platform for enterprise Java apps and for R&D infra. (Interesting how developer and sysadmin roles converge to some extent when cloud is your platform...) Automating setup of development and CI servers, using Puppet and common UNIX tools.
Updated on September 17, 2022Comments
-
geekyaleks almost 2 years
A Debian Stable (5.0.3) server is running
ntpd
, and connected to the internet. Still, the system clock is about 5 minutes wrong.$ /etc/init.d/ntp status NTP server is running..
Relevant parts (I think) of
/etc/ntp.conf
:driftfile /var/lib/ntp/ntp.drift statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 0.europe.pool.ntp.org server 1.europe.pool.ntp.org server 2.europe.pool.ntp.org server 3.europe.pool.ntp.org
I know NTP doesn't necessarily bring the clock in time immediately. Still, how many hours or days you need to wait in order to reasonably expect that NTP has done its job and synced the clock?
Am I missing some other configuration file or option, or just doing something wrong? Is ntp (instead of e.g. ntpdate) the right tool for this? Is there any quick way to check if configuration is correct and whether the chosen NTP servers return the correct time?
Edit: output of
ntpq -p
is:remote refid st t when poll reach delay offset jitter ============================================================================== ns1.nexellent.n .INIT. 16 u - 1024 0 0.000 0.000 0.000 dnscache-madrid .INIT. 16 u - 1024 0 0.000 0.000 0.000 sinister.wzw.tu .INIT. 16 u - 1024 0 0.000 0.000 0.000 dnscache-frankf .INIT. 16 u - 1024 0 0.000 0.000 0.000
Edit 2: Turns out
ntpdate -u 0.europe.pool.ntp.org
command (suggested by brent) returns17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
...even though on other machines that command works fine. So we'll be looking at network/firewall settings for this particular server (which is in a different network, accessed over VPN).
Resolution: The culprit wasn't local firewall on our server, but firewall settings somewhere in the surrounding network. So we asked the server hosting provider to allow NTP for our machines, and now it works fine. For example,
ntpq -p
now returns:remote refid st t when poll reach delay offset jitter ============================================================================== ns1.eunet.fi 192.36.144.23 2 u 10 64 1 1.043 0.258 0.001 ns2.eunet.fi 62.142.10.44 2 u 9 64 1 0.671 0.135 0.001 ns3.eunet.fi 62.142.10.44 2 u 8 64 1 0.750 0.277 0.001
(We also switched to eunet.fi servers recommenced by the hosting company, but that is beside the point.) The commands in brent's answer were helpful because they made me realise the problem was in network access to the NTP servers, not in NTP configuration itself. Thanks everyone!
-
jscott over 14 yearsWhat's the output of 'ntpq -p'?
-
-
jscott over 14 yearsAnd the 'when' field should indicate time since last packet received.
-
geekyaleks over 14 yearsThe ntpdate command returns something like "17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found". However, on other machines the same command gives something meaningful! I'm starting to suspect that some firewall settings for this particular server cause the problem...
-
geekyaleks over 14 yearsWe'll see tomorrow if we can sort out those network/firewall settings. I'll accept this for now, because most likely the problem is related to those. Thanks for pointing me to the right direction!
-
geekyaleks over 14 yearsThanks. In this case the problem seems to be that we cannot see the NTP server without problem - see the comments to brent's answer: serverfault.com/questions/95342/…
-
geekyaleks over 14 yearsYeah, that most likely is the problem; see comments to this answer: serverfault.com/questions/95342/…
-
Mike over 9 yearsThe
ntpdate
command works and syncs my clock, but all values are still0
after I restartntp
. Why would it work if I do it manually, but not usingntpd
? I'm on Debian btw. -
Florian Heigl over 5 yearsdoing that from ntpdate instead of correcting the issue with ntp is pretty useless long-term. and i would know no reason why to run it three times.
-
brent over 5 yearsThe point was to bring their clock into alignment immediately. In the initial post before the edits, they were not aware that there was a network issue. These commands helped them come to the conclusion that there was a network problem. Running the command 3 times was to ensure the clock was brought into alignment immediately as ntp implementations vary in how they do things. It was to simply be sure the clock was where it should be. Considering this is one of my most upvoted comments, it seems to have helped a lot of people. Thanks for your useful addition nearly 10 years later @FlorianHeigl