Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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) returns

17 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!

share|improve this question
1  
What's the output of 'ntpq -p'? –  jscott Dec 17 '09 at 15:00

3 Answers 3

up vote 9 down vote accepted

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.

share|improve this answer
1  
And the 'when' field should indicate time since last packet received. –  jscott Dec 17 '09 at 15:30
    
The 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... –  Jonik Dec 17 '09 at 15:46
    
We'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! –  Jonik Dec 17 '09 at 15:57

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.

share|improve this answer
    
Thanks. 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/… –  Jonik Dec 18 '09 at 8:19

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).

share|improve this answer
    
Yeah, that most likely is the problem; see comments to this answer: serverfault.com/questions/95342/… –  Jonik Dec 18 '09 at 8:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.