Tracking down “ntpdate[18168]: no server suitable for synchronization found”


After installing and getting up ntpd on a RHEL-like Linux system, see http://www.certdepot.net/rhel7-set-ntp-service for example, you may want to double check iff ntpd is actually able to perform successfully. There’s a couple of shell commands to employ, most notably ntpstat and ntpq as well as timedatectl more recently with version 7 and up systems. ntpstat will tell you about the status of the time synchronisation, whereas ntpq, being executed a few times in a row, shows the servers being selected for synchronisation, the one prefixed by an aterisk as the current master, and the time left since the last synchronisation up the the synchronisation interval in the when and poll columns, respectively. timedatectl furthermore includes timezone and daylight saving information, however, the synchronisation status given here is about to be called into question, see later. So far, iff anything runs fine, you may expect something like this (consider the values changing in the when column for the second call):

[root@xyz ~]# ntpstat ; ntpq -p
synchronised to NTP server (46.165.212.205) at stratum 3
   time correct to within 61 ms
   polling server every 1024 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*mail.danzuck.eu 192.53.103.104   2 u  200 1024  377   17.679   -3.330   0.514
+zulu321.server4 5.9.110.236      3 u   74 1024  377   10.650    4.482   0.222
-panel1.web2.clu 5.9.122.148      3 u    3 1024  377   18.589    5.814   0.274
+e-avenue.gr     213.239.239.164  3 u  147 1024  377    7.273    2.899   0.297

[root@xyz ~]# ntpstat ; ntpq -p
synchronised to NTP server (46.165.212.205) at stratum 3
   time correct to within 62 ms
   polling server every 1024 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*mail.danzuck.eu 192.53.103.104   2 u  237 1024  377   17.679   -3.330   0.514
+zulu321.server4 5.9.110.236      3 u  111 1024  377   10.650    4.482   0.222
-panel1.web2.clu 5.9.122.148      3 u   40 1024  377   18.589    5.814   0.274
+e-avenue.gr     213.239.239.164  3 u  184 1024  377    7.273    2.899   0.297

[root@xyz ~]# timedatectl status
      Local time: Thu 2016-02-04 10:57:10 CET
  Universal time: Thu 2016-02-04 09:57:10 UTC
        RTC time: Thu 2016-02-04 09:57:10
        Timezone: Europe/Berlin (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2015-10-25 02:59:59 CEST
                  Sun 2015-10-25 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2016-03-27 01:59:59 CET
                  Sun 2016-03-27 03:00:00 CEST

Yet on another machine, after getting up ntpd, ntpstat consistently reported an unsynchronized state. The information given by ntpq did accordingly not start to develop in terms of the when column. In fact, the refid column remained at some .INIT. state for ever (far longer than the max 1024secs or ~17mins, as documented). Note that, as advertized above, # timedatectl status is obviously wrong and questionable here stating that NTP synchronized: yes (??!), like this:

[root@xyz etc]# ntpstat ; ntpq -p
unsynchronised
  time server re-starting
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 tschil.ethgen.c .INIT.          16 u    -  512    0    0.000    0.000   0.000
 gromit.nocabal. .INIT.          16 u    -  512    0    0.000    0.000   0.000
 intrepid.memory .INIT.          16 u    -  512    0    0.000    0.000   0.000
 ridcully.episod .INIT.          16 u    -  512    0    0.000    0.000   0.000

[root@xyz etc]# timedatectl status
      Local time: Thu 2016-02-04 08:41:42 CET
  Universal time: Thu 2016-02-04 07:41:42 UTC
        RTC time: Thu 2016-02-04 07:41:42
        Timezone: Europe/Berlin (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2015-10-25 02:59:59 CEST
                  Sun 2015-10-25 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2016-03-27 01:59:59 CET
                  Sun 2016-03-27 03:00:00 CEST

Not shure what this means at all… still initializing or some real problem? Let’s try ntpdate, which provides for a manual time synchronization on the code stack of ntpd against a truly reliable NTP pool host (and expects ntpd not to run concurrently !):

[root@xyz etc]# systemctl stop ntpd
[root@xyz etc]# ntpdate pool.ntp.org
 4 Feb 09:32:24 ntpdate[9385]: no server suitable for synchronization found

Really? But ntpq does have servers on the records as seen above… so what now? According to http://askubuntu.com/questions/134969/ntpd-server-always-in-init-mode and http://askubuntu.com/questions/429306/ntpdate-no-server-suitable-for-synchronization-found, amongst others, communication between your ntpd (host) and some outer NTP host seems to be broken or supressed for this or that or even another reason. An investigation should therefore examine the full ntpd communication roundtrip from your host to the outer host and back. Do note here, that ntpd talks UDP on 123, where UDP is not the default for most network analysis tools and needs to be specified by dedicated switches. Firstly, see what happens on localhost:123 (ntpd must of course be running again):

[root@xyz etc]# systemctl start ntpd
[root@xyz etc]# nmap -p123 -sU -P0 localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2016-02-04 09:41 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).
Other addresses for localhost (not scanned): 127.0.0.1
PORT    STATE SERVICE
123/udp open  ntp
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

Ok, so there does not seem to be some firewall issue around. Secondly, try to raw talk to the NTP pool host, just looking out for a rejected connection:

[root@xyz etc]# systemctl stop ntpd
[root@xyz etc]# ncat -uv pool.ntp.org 123
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 87.118.124.35:123.

Nothing rejected, fine again, we may walk outdoors. But finally back in again also? This may take another call to ntpdate, in debug mode this time to be utterly about what is being done upon the request (I’m not giving the complete output here, only what is necessary, see below):

[root@xyz etc]# systemctl stop ntpd
[root@hamgujhso003 etc]# ntpdate -udv pool.ntp.org
 4 Feb 09:34:54 ntpdate[10833]: ntpdate 4.2.6p5@1.2349-o Mon Jan 25 14:25:26 UTC 2016 (1)
Looking for host pool.ntp.org and service ntp
host found : ns2.customer-resolver.net
transmit(62.116.130.3)
transmit(5.9.7.51)
transmit(178.23.121.165)
transmit(78.46.37.9)
transmit(62.116.130.3)
...
 4 Feb 09:35:02 ntpdate[10833]: no server suitable for synchronization found
[

No errors, so what’s wrong. Doing the same call on a working ntpd environment tells the difference then. Regard the receive output lines after any transmit to be watched out for:

[root@fup-vm-srch-03 ~]# ntpdate -udv pool.ntp.org
 4 Feb 12:55:03 ntpdate[10973]: ntpdate 4.2.6p5@1.2349-o Sat Dec 20 01:24:56 UTC 2014 (1)
Looking for host pool.ntp.org and service ntp
host found : ntp.goneco.de
transmit(212.112.228.242)
receive(212.112.228.242)
transmit(78.47.249.19)
receive(78.47.249.19)
transmit(62.75.254.179)
receive(62.75.254.179)
...
 4 Feb 12:55:09 ntpdate[10973]: adjust time server 62.75.254.179 offset 0.003378 sec

So obviously, there’s some incoming firewall rule in place on the ISP layer that prevents the response from the NTP server to pass through. Under such circumstances, your ISP will most probably run an own NTP server to connect to. You should change the server directives in /etc/ntp.conf accordingly.

Have fun, Peter

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s