NTP RHEL6 – NTP Can’t Synchronize or Find a Suitable Server

ntpntpdaterhel6

The problem I'm trying to solve is that NTP won't synchronize:

$ sudo ntpstat
unsynchronised
  time server re-starting
   polling server every 64 s

Edit: Here's some ntpq output:

$ sudo ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp.eecs.wsu.ed .INIT.          16 u    -   64    0    0.000    0.000   0.000
 71.19.224.242   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 ntp4.vps.net    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 mercury.z0p.org .INIT.          16 u    -   64    0    0.000    0.000   0.000
 li506-17.member .INIT.          16 u    -   64    0    0.000    0.000   0.000
 4.53.160.75     .INIT.          16 u    -   64    0    0.000    0.000   0.000
 ntp1.ResComp.Be .INIT.          16 u    -   64    0    0.000    0.000   0.000

I have the default RHEL6 /etc/ntp.conf configuration. Servers bit:

server 0.rhel.pool.ntp.org
server 1.rhel.pool.ntp.org
server 2.rhel.pool.ntp.org

When I stop ntpd and try to run ntpdate manually, I get a "no server suitable for synchronization found" for all of those servers. Here's ntpdate with debug output:

$ ntpdate -dq 1.rhel.pool.ntp.org
10 May 10:02:42 ntpdate[13320]: ntpdate 4.2.4p8@1.1612-o Thu May 13 14:38:25 UTC 2010 (1)
Looking for host 1.rhel.pool.ntp.org and service ntp
host found : caprica.willglynn.com
transmit(208.88.126.226)
transmit(66.225.61.66)
transmit(149.20.68.17)
transmit(4.53.160.75)
transmit(208.88.126.226)
transmit(66.225.61.66)
transmit(149.20.68.17)
transmit(4.53.160.75)
transmit(208.88.126.226)
transmit(66.225.61.66)
transmit(149.20.68.17)
transmit(4.53.160.75)
transmit(208.88.126.226)
transmit(66.225.61.66)
transmit(149.20.68.17)
transmit(4.53.160.75)
transmit(208.88.126.226)
transmit(66.225.61.66)
transmit(149.20.68.17)
transmit(4.53.160.75)
208.88.126.226: Server dropped: no data
66.225.61.66: Server dropped: no data
149.20.68.17: Server dropped: no data
4.53.160.75: Server dropped: no data
server 208.88.126.226, port 123
stratum 0, precision 0, leap 00, trust 000
refid [208.88.126.226], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036  1:28:16.000
transmit timestamp:  d5377c86.25dd5f5a  Fri, May 10 2013 10:02:46.147
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 66.225.61.66, port 123
stratum 0, precision 0, leap 00, trust 000
refid [66.225.61.66], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036  1:28:16.000
transmit timestamp:  d5377c86.591061f7  Fri, May 10 2013 10:02:46.347
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 149.20.68.17, port 123
stratum 0, precision 0, leap 00, trust 000
refid [149.20.68.17], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036  1:28:16.000
transmit timestamp:  d5377c86.8c427d35  Fri, May 10 2013 10:02:46.547
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 4.53.160.75, port 123
stratum 0, precision 0, leap 00, trust 000
refid [4.53.160.75], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036  1:28:16.000
transmit timestamp:  d5377c86.bf762a87  Fri, May 10 2013 10:02:46.747
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

10 May 10:02:47 ntpdate[13320]: no server suitable for synchronization found

I can ping some of the NTP servers the pool directs me to:

$ ping caprica.willglynn.com
PING caprica.willglynn.com (208.88.126.226) 56(84) bytes of data.
64 bytes from caprica.willglynn.com (208.88.126.226): icmp_seq=1 ttl=52 time=60.2 ms
64 bytes from caprica.willglynn.com (208.88.126.226): icmp_seq=2 ttl=52 time=59.6 ms
64 bytes from caprica.willglynn.com (208.88.126.226): icmp_seq=3 ttl=52 time=59.9 ms
64 bytes from caprica.willglynn.com (208.88.126.226): icmp_seq=4 ttl=52 time=59.8 ms

Netstat for port 123:

$ netstat -ano|grep 123
udp        0      0 10.0.116.6:123              0.0.0.0:*                               off (0.00/0/0)
udp        0      0 127.0.0.1:123               0.0.0.0:*                               off (0.00/0/0)
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               off (0.00/0/0)
udp        0      0 :::123                      :::*                                    off (0.00/0/0)

iptables and ip6tables are off, but there is an external firewall that should have port 123 open for UDP.

Best Answer

Make sure there isn't an external firewall between the machine and the rest of the internet. If there is, request that the people administering the firewall open port 123.

Related Solutions

Linux – Single NTP server on isolate network

NTP should work fine. Look at some of the options for fast synchronization on start-up. Look at the burst and iburst options for the system B. Look at the true option for the GPS clock source.

Consider using the hardware clock as a backup time source on both systems. Set a higher stratum system B. Something like the following should work:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Watch the output of ntpq -c peers to see when you get a trusted clock source. Normally ntp wants a number of responses from a trusted time source before it trusts it. This is indicated by the first character on each line.

While NTP likes more sources, any odd number of time sources within one stratum level should work well. As you only have two servers and a GPS clock the priority (stratum) of the sources should increase from GPS, clock on server A, clock on server B. Increasing the stratum between each by three or four levels will ensure priorities are respected.

EDIT: If you have the busybox NTP server on server A, it may be worthwhile installing the full ntp server package. Understanding what is happening with server A should go a long way to solving your problem. You will need at least one trusted time source there before server B should trust it. If ntpq -c peers doesn't work, then you can try ntpdc peers. Both these commands allow you to query other hosts. A peerstats log could also be useful.

On server B use ntpclient as documented the busybox ntp howto to log what is happening on it

The clocks should be reasonably close to the correct time if the servers haven't been down for long. If you need to sync the two systems, that should be sufficient. The GPS will bring the time into sync with the real world eventually.

'ntpd -q' synchronizes quickly, but exits (ntpdate behaviour). It needs to be followed by an ntpd command without the quit option to have continuous synchronization.

EDIT2: I check my server and found one of the servers was off by a second. While fixing this I played with the settings. iburst gets a server trusted very quickly. true ensured the clock driver was trusted if there weren't multiple other trusted sources. The clock took a little more than a minute before it was locally trusted and could be trusted remotely.

When testing you should be able to restart the ntpd process once it is synchronized and test how fast settings work. In the above case Server B may need to be restarted to test how fast it synchronizes. When monitoring ntpd changes I use a line like:

while ntpq -c peers localhost; do sleep 10; done

The hostname and sleep time are adjusted as require. In some cases I chain two or more ntpq command lines in the loop. When doing so I use an echo and/or date command to provide an indication of where sets of data change.

Linux – NTP not syncing automatically with the internal NTP server

Looks like I was just being impatient. After a reboot if I wait about 6 minutes and ran ntpstat it will show it is synchronized.

The polling interval says 64 s which I assumed meant it polls every 64 s, but it looks like it doesn't work like that exactly.

Best Answer

Related Solutions

Linux – Single NTP server on isolate network

Linux – NTP not syncing automatically with the internal NTP server

Related Topic