3

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
Arpith
  • 274
  • 6
  • 17
  • 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 09:55

2 Answers2

4

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.

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
  • 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
0

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.

deed02392
  • 278
  • 1
  • 5
  • 16
  • 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