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

I setup an NTP server on a machine in another subnet and tried to ync my machine with the server and it works well. But when I try to ust the pool.ntp.org servers (I tried 0.pool.ntp.org, 1.pool.ntp.org, etc. and just pool.ntp.org servers), it does not sync.

nslookup on pool.ntp.org as well as 0.pool.ntp.org gives proper DNS resolution and ping works on the IPs returneed by nslookup as well.

Output of iptables grepped for UDP is as follows:

[Thu Feb 10 12:39:14 root@root-ubuntu:~]# iptables -L -n -v | grep udp

92 13001 ACCEPT    udp -- *    *     0.0.0.0/0          0.0.0.0/0         state RELATED,ESTABLISHED 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:123 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:161 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:443 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:623 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:389 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:636 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:3268 
0     0 ACCEPT     udp -- *    *     0.0.0.0/0          0.0.0.0/0         udp dpt:3269 

Output of the netstat command is as follows:

[Thu Feb 10 12:35:51 root@root-ubuntu:~]# netstat -a | grep udp

udp        0      0 localhost:9473                 0.0.0.0:*                           
udp        0      0 0.0.0.0:asf-rmcp               0.0.0.0:*                           
udp        0      0 173.39.22.123:ntp              0.0.0.0:*                           
udp        0      0 localhost:ntp                  0.0.0.0:*                           
udp        0      0 0.0.0.0:ntp                    0.0.0.0:*                           
udp        0      0 all-systems.mcast.net:23000    0.0.0.0:*                           
udp        0      0 ::1:ntp                        ::%628620:*                         
udp        0      0 fe80::222:bdff:feea:9f1f:ntp   ::%628620:*                         
udp        0      0 fe80::222:bdff:feea:9f20:ntp   ::%628620:*                         
udp        0      0 :::ntp                         ::%628620:*

I am unable to figure out why the sync problem is happening only with the pool servers and not the local server. The UDP ports in my system is up. The servers are up. Time however does not sync (It is still displaying Feb 10.)

[EDIT] Adding my .conf file:

driftfile /tmp/ntp.drift/
server 0.pool.ntp.org

Adding ntpq -p data:

[Thu Feb 10 14:13:51 root@root-ubuntu:~]# ntpq -p 0.pool.ntp.org

     remote           refid      st t when poll reach   delay   offset  jitter
============================================================================== 
*64.147.116.229  .ACTS.           1 u  151 1024  377    2.439   -0.632   0.052  
+131.107.13.100  .ACTS.           1 u  879 1024  377   27.853    1.041   0.539  
-time.nrc.ca     132.246.11.231   2 u  989 1024  377   86.821   -4.132   8.778  
-time1.chu.nrc.c 209.87.233.52    2 u   53 1024  377  109.221    3.153   9.377  
+dense.utcc.utor 128.100.200.166  2 u   88 1024  377   64.115   -1.841   0.454  
-dns4.utoronto.c 128.100.103.253  2 u  167 1024  377   65.252  -43.422  56.093
share|improve this question
1  
+1 just for adding useful iptables info right off the bat. The counts on the first udp line suggest that your firewall is not the problem. What's the output of ntpq -p? –  Ladadadada Dec 11 '12 at 9:55

2 Answers 2

Oh wait. February 10th? No. ntp will not sync that far. It's for seconds and milliseconds; not hours and days.

You should set the date roughly with date or accurately with ntpdate first.

share|improve this answer
    
Both of those solutions are considered obsolete. Use ntpd -g on modern systems. –  David Schwartz Dec 11 '12 at 10:07
    
@Ladadadada: I am using ntpd with the -g and -n flags to ensure that ntpd does not quit due to panic thresholds. –  Arpith Dec 11 '12 at 10:08
    
Interesting. I didn't know about the -g option. Does it wait for a reach of 377 with at least one server before setting the time or does it set the time immediately after the first response? You might just need to wait. The output of ntpq -p could still be helpful here. The next steps would be looking in your syslog for error messages or using tcpdump to verify the network part of the protocol. –  Ladadadada Dec 11 '12 at 10:33

It is getting the time from the NTP server, but it won't adjust the system time so dramatically automatically because this could cause serious problems. Hence you must set the date manually to the approximate time, preferably within a minute, or use an alternative program for syncing the time which will bring you gradually up to date by using incremental time steps.

If you are often days or months out of date, however, you should resolve why this is happening instead of expecting it to be fixed automatically. Imagine what those kind of time jumps could be doing to your server logs and databases for example - this is why NTP clients will not sync over such drastic differences.

Alternatives I can think of which sensibly adjust the time in-line with a server are chrony and proxmox.

share|improve this answer
    
It sets the time from January 1, 1970 to the present date with the local NTP server. It does not sync at all with the pool NTP servers. If it was a problem with the way NTP was configured it shouldn't have worked with any NTP servers. –  Arpith Dec 11 '12 at 10:12
    
I advise following Lada*'s advice on checking logs and dumping network data during an attempted sync. –  deed02392 Dec 11 '12 at 10:52
    
ntpd is capable of all these functions: 1. syncing the time which will bring you gradually up to date by using incremental time steps 2. adjust the system time dramatically causing disruption or gradually without disrupting time sensitive applications by udsing the appropriate keywords in the .conf file (such as tinker, etc). In view of these, your answer is not very helpful. But thank you nevertheless. –  Arpith Dec 11 '12 at 12:52
    
Yes I agree with you, I think lower level investigation is needed. Check actual data traffic with tcpdump to confirm it's not a network issue. –  deed02392 Dec 11 '12 at 13:25

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.