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

fudge 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 ::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   2 u   30   64  377  220.331   31.973   0.491
-   2 u  107   64  346  151.095    8.540   8.537
+uk.cluster.ntp.  2 u   28   64  377  133.718   -2.215   0.278
+t2.time.sg3.yah    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
  • Can you paste the output of ntpdate -q time2.google.com? Dec 12, 2018 at 10:15
  • server, stratum 1, offset 0.002145, delay 0.19994 12 Dec 14:45:16 ntpdate[4755]: adjust time server offset 0.002145 sec Dec 12, 2018 at 10:45
  • My issue got solved on its own. No idea how or why!! Dec 12, 2018 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. Dec 12, 2018 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. Dec 13, 2018 at 6:09

2 Answers 2


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.


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 and fudge 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.