no server suitable for synchronization found

[Hakki Aydin Ucar]

I got the following error after issue the command,

/sbin/init.d/xntpd start

no server suitable for synchronization found.

If I try to manually , 

/sbin/init.d/xntpd stop

ntpdate IP

it is working , but not working by xntpd stop / start even though that I believe .etc.ntp.conf is correct

and besides one of the server ntp sync not works even though I try to manually by the command ntpdate..

This is the output of ntpdate -d IP output:

# ntpdate -d 10.206.172.27
transmit(10.206.172.27)
receive(10.206.172.27)
transmit(10.206.172.27)
receive(10.206.172.27)
transmit(10.206.172.27)
receive(10.206.172.27)
transmit(10.206.172.27)
receive(10.206.172.27)
transmit(10.206.172.27)
server 10.206.172.27, port 123
stratum 1, precision -16, leap 00, trust 000
refid [], delay 0.03026, dispersion 0.00052
transmitted 4, in filter 4
reference time: dd60ed09.d57986d8 Mon, Sep 11 2017 14:07:53.833
originate timestamp: dd60ed09.d57986d8 Mon, Sep 11 2017 14:07:53.833
transmit timestamp: dd60eabd.1fb34000 Mon, Sep 11 2017 13:58:05.123
filter delay: 0.03026 0.03043 0.03233 0.03381
0.00000 0.00000 0.00000 0.00000
filter offset: 588.7042 588.7043 588.7051 588.7059
0.000000 0.000000 0.000000 0.000000
delay 0.03026, dispersion 0.00052
offset 588.704224

11 Sep 13:58:05 ntpdate[234]: step time server 10.206.172.27 offset 588.704224 sec

any advise ?

[Matti_Kurkela · Accepted solution]

1.) With the -d option, ntpdate won't actually change the system clock: it only shows you what it would do. In your example, if you ran the same command without the -d option, it would adjust the clock forward by about 588.7 seconds.

2.) The "no server suitable for synchronization found" message comes from ntpdate, not from xntpd. In /etc/rc.config.d/netdaemons configuration file, there is a configuration variable named NTPDATE_SERVER. When it is set, the startup script for xntpd will first use ntpdate to make as large adjustments as needed to the system time using the NTP server listed in the NTPDATE_SERVER variable. After ntpdate has done its job, then xntpd will be started to make sure the system clock will stay in sync with the time sources listed in /etc/ntp.conf.

You need to be aware of this! If you ever need to restart xntpd while some application process that is sensitive to sudden system clock changes, and especially you have NTPDATE_SERVER set, it will not be safe to use "/sbin/init.d/xntpd start". Instead, in such a situation you should use "/usr/sbin/xntpd -x" to restart xntpd to avoid any chance of step-style changes to the system clock. "/sbin/init.d/xntpd start" is designed to be used when the system is starting up and applications are not yet running, so it assumes that step changes are safe.

So, the message you're seeing with "/sbin/init.d/xntpd start" probably happens because the NTPDATE_SERVER variable in your /etc/rc.config.d/netdaemons file has an old, forgotten, incorrect setting.

Even though "/sbin/init.d/xntpd start" outputs the error message, it might still be starting xntpd. If you don't see the xntpd process running after you run that command, you should check for syntax errors in /etc/rc.config.d/netdaemons file or any error messages from xntpd in the logs. Since /etc/rc.config.d/netdaemons is a shell script file that is supposed to contain only environment variable settings, you can check it for errors by simply running it in a sub-shell as a non-root user:

$ sh /etc/rc.config.d/netdaemons
$

If there are no error messages, the script is syntactically OK.

To check for error messages logged by xntpd, run:

# grep xntpd /var/adm/syslog/syslog.log

When starting up, xntpd should normally log two messages like this:

xntpd[18352]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
xntpd[18352]: precision = 10 usec

And if it can contact the NTP servers configured in /etc/ntp.conf, 5 minutes or so later a third message should be logged:

xntpd[18352]: synchronized to 192.0.2.1, stratum=1

When xntpd is running, the best way to verify its functionality is to use the "ntpq -p" command:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
 192.0.2.66     0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0
 192.0.2.67     0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0
*192.0.2.1      .MRS.            1 u   56   64  377     1.74    2.087    0.35
+192.0.2.2      .MRS.            1 u   56   64  377     1.75    2.096    0.40
+192.0.2.3      .MRS.            1 u   56   64  377     2.01    2.054    0.35

In this example, xntpd has been running for at least about 10 minutes, so it has successfully polled 192.0.2.1, .2 and .3 for at least 8 times, as indicated by the octal bitmap value in the "reach" column. 192.0.2.66 and 192.0.2.67 are apparently unreachable, as their reach value is still 0 and stratum values are 16.

Note the asterisk and the plus signs in the first column of the output: they indicate that 192.0.2.1 is the service xntpd is currently successfully synchronized with, and 192.0.2.2 and 192.0.2.3 are the next candidates, should 192.0.2.1 fail or become unreachable.