Here's
ntpq -pn output from one of my time servers (as an aside, it's a
pool server -- more NTP servers would be welcome).
Code: Select all
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+194.100.49.152 193.166.4.49 2 u 607 1024 377 1.101 0.080 0.277
+178.251.154.103 194.100.2.194 2 u 684 1024 377 0.868 0.140 0.796
*194.100.2.194 .GPS. 1 u 771 1024 377 0.802 0.119 0.359
-185.31.136.34 193.79.237.14 2 u 555 1024 377 1.051 -2.489 0.537
The important thing here is the
* in the first column. It marks the upstream time source ntpd has synchonized with.
If you run
grep ntpd /var/log/messages you may get some information about why ntpd has failed to synchonize with the specified upstream time source.
Some old Windows Servers were not suitable as NTP time sources because they only supplied the time with a one second precision, but I think Windows Server 2016 is new enough so that this isn't a problem.
You could try synchonizing the clock manually to see if it works. Steps to do that:
Code: Select all
# systemctl stop ntpd.service
# ntpdate your.time.server
10 Mar 15:23:01 ntpdate[44447]: adjust time server your.time.server offset 0.030762 sec
# ntpdate your.time.server
10 Mar 15:23:09 ntpdate[44458]: adjust time server your.time.server offset 0.001049 sec
# systemctl start ntpd.service
You will need to stop ntpd before setting the clock. The reason for running ntpdate twice is to see that your clock was indeed set to the correct time. The offset in the output of the second invocation of ntpdate should be significantly smaller than in the first, like one millisecond in the above example. Finally restart the ntpd service again.
