3

I have DMZ server configured as NTP server to connect to external NTP servers and sync time in all devices in my corporate network. Below are the contents of my ntp.conf file in the DMZ server

server 127.127.1.0
fudge 127.127.1.0 stratum 6
driftfile /var/lib/ntp/ntp.drift

logfile /var/log/ntpd.log

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


server 0.asia.pool.ntp.org iburst
server 1.asia.pool.ntp.org iburst
server 2.asia.pool.ntp.org iburst
server 3.asia.pool.ntp.org iburst
server time.google.com iburst

restrict -4 default kod nomodify notrap
restrict 127.0.0.1
restrict ::1

However, there is a 27 seconds difference with the local time in UAE (timezone server is in) and the server "date". I executed below commands and reboots of server, multiple times. This is a Debian 9.6 server. I did all package updates in server, still 27 seconds difference.

/etc/init.d/ntp stop
ntpdate -u 0.asia.pool.ntp.org
/etc/init.d/ntp start
hwclock -w
ntpq -p

ntpq -p output is as below:

~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.           6 l  709   64    0    0.000    0.000   0.000
-ntp.paina.net   131.113.192.40   2 u   30   64  377  220.331   31.973   0.491
-119.28.206.193  100.122.36.196   2 u  107   64  346  151.095    8.540   8.537
+uk.cluster.ntp. 185.134.196.169  2 u   28   64  377  133.718   -2.215   0.278
+t2.time.sg3.yah 106.10.133.18    2 u   28   64  377   95.837    5.051   0.602
*time2.google.co .GOOG.           1 u   30   64  377  163.875   -6.637   0.338
Arun Krishnan
  • 339
  • 2
  • 3
  • 12
  • Can you paste the output of `ntpdate -q time2.google.com`? – David Schwartz Dec 12 '18 at 10:15
  • `server 216.239.35.4, stratum 1, offset 0.002145, delay 0.19994 12 Dec 14:45:16 ntpdate[4755]: adjust time server 216.239.35.4 offset 0.002145 sec` – Arun Krishnan Dec 12 '18 at 10:45
  • My issue got solved on its own. No idea how or why!! – Arun Krishnan Dec 12 '18 at 14:29
  • My guess is that the NTP software corrected the discrepancy. With at least the standard NTP daemon, time only gets adjusted slowly if it's within about 30 seconds of the correct value so that applications and clients don't see a sudden jump in the value of the clock (which could break applications and cause issues for NTP clients who are syncing from more than one server). IIRC, with normal behavior, a 27 second offset should take multiple hours to correct using this slow method. – Austin Hemmelgarn Dec 12 '18 at 16:19
  • The 27 seconds difference lasted for 8 hours. After 9 hours while checking I found it got corrected on its own. So in this one hour some magic happened. May be its NTP itself or something else. – Arun Krishnan Dec 13 '18 at 06:09

2 Answers2

3

I had the same problem on FreeBSD, and figured out the following:

27 is exactly the number of leap seconds between 1/1/1970 (when the Unix clock started to tick) and today. Therefore most likely the problem is related to leap seconds. Things to check:

  • Leap seconds database file

The ntpd should have a leap seconds database file installed. The daemon does report to the system logs when it finds this file and if it is good.

  • Upstream time servers

There do exist time servers that provide time for other purposes than our kind of servers, and these may handle leap seconds differently. Use ntpdate -q to compare the opinion of your upstream time server with a well-known server on the internet.

  • timezone database

The timezone database can be built with or without support for leap seconds. If you somehow manage to install the wrong variant, there will be (currently) 27 seconds offset on your localtime. The difference is visible when comparing date and TZ=UTC date.

PMc
  • 31
  • 2
2

This is may not be the solution to your original problem, but there are a couple of things in your configuration which you should change:

  1. Remove the deprecated local clock driver and use orphan mode instead. Replace: server 127.127.1.0 and fudge 127.127.1.0 stratum 6 with tos orphan 6. (See the NTP docs for more info on orphan mode.)

  2. Use either the NTP pool or Google's time service, but not both. The reason for this is that you're mixing leap-smeared and non-leap-smeared time sources.

Paul Gear
  • 3,938
  • 15
  • 36