On Debian 10, ntpd [email protected] fails to sync with following error:

kernel reports TIME_ERROR: 0x41: Clock Unsynchronize

here's ntp.conf:

disable monitor

statsdir /var/log/ntpstats

restrict -4 default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict ::1

server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst
server 3.us.pool.ntp.org iburst

fudge stratum 10

driftfile /var/lib/ntp/drift

ntpq -c sysinfo:

associd=0 status=0614 leap_none, sync_ntp, 1 event, freq_mode,
system peer:        50-205-57-38-static.hfc.comcastbusiness.net:123
system peer mode:   client
leap indicator:     00
stratum:            2
log2 precision:     -23
root delay:         70.634
root dispersion:    3.569
reference ID:
reference time:     e3a0c049.c39d770a  Wed, Jan  6 2021 23:03:37.764
system jitter:      0.723169
clock jitter:       1.177
clock wander:       0.000
broadcast delay:    -50.000
symm. auth. delay:  0.000

ntpq -c lpeers:

     remote           refid      st t when poll reach   delay   offset  jitter
 LOCAL(0)        .LOCL.          10 l  286   64   20    0.000    0.000   0.000
*50-205-57-38-st .GPS.            1 u   19   64   37   70.631    1.618   1.843
-ns1.backplanedn  2 u   14   64   37   84.235   -1.575   2.852
+c-73-239-136-18      3 u   11   64   37   48.606    1.598   2.522
+time-d.bbnx.net   2 u   14   64   37   92.632    0.623   0.799


               Local time: Wed 2021-01-06 23:06:44 UTC
           Universal time: Wed 2021-01-06 23:06:44 UTC
                 RTC time: Wed 2021-01-06 23:06:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Any idea what could be wrong?

  • 3
    Probably nothing is wrong, and it's just a misleading warning message at startup. See, for example, linuxquestions.org/questions/slackware-14/…. Apart from this message, are there any other symptoms that worry you? Is the time correct? This computer seems to get its time from a GPS device, and the difference between GPS time and computer time is a mere millisecond (offset column in the peers table). Jan 7, 2021 at 0:28
  • Thanks. I'm worried about kernel reporting unsynced clock. ntp seems to need more time to sync. I've tried using chrony and it reports synced time immediately.
    – Tombart
    Jan 7, 2021 at 8:08

2 Answers 2


Your clock is syncing fine. The sync_ntp in your ntpq -c sysinfo proves that. The kernel messages you're referring to are transient during ntpd startup and are not anything to be worried about.

The problems I see with your setup:

  1. timedatectl is not reporting time sync correctly. The easy fix for that is not to run it. :-) On one of my servers on the same OS and NTP version, timedatectl doesn't produce anything useful at all, but instead says Failed to create bus connection: No such file or directory, because I don't run dbus.
  2. I'm surprised your configuration works with pool servers at all, because of the lack of a restrict source ... line.
  3. You're using the LOCL clock driver, which has been deprecated for many years.
  4. Similarly, you don't need disable monitor to protect yourself from being used for reflective DDoS - the default restrict lines handle that.

You should revert to the default Debian /etc/ntp.conf contents - it will work better than your current configuration and cause you fewer problems when you upgrade. Here's a copy, in case you don't have one handy: http://paste.debian.net/1180011/


I've had a multi-second time drift and similar error messages and I've solved it with:

systemctl stop ntpd
systemctl start ntpdate  # takes some seconds to succeed
systemctl start ntpd

After that, the time drift was gone. Solution taken from opensuse forums here

  • There is usually never a need to run this - ntpd is usually started with the -g flag on modern systems, which will do what ntpdate does, but without needing to use a deprecated utility.
    – Paul Gear
    Aug 2 at 11:33
  • @PaulGear "usually never"? I had to run this on my ArchLinux system this year. Especially strange to see criticism of my answer that I've written because it worked on my system, and the other solutions I was trying did not -- all while you have your own answer above as well. Aug 2 at 13:31
  • * I've now edited my answer to be clear(er) on the fact that the time drift was real -- not just the error messages. Aug 2 at 13:34
  • I guess my wording could use some work as well. I would have said "never" because all distros I'm familiar with start ntpd with -g, which will step the clock up to 1000 seconds on startup, but I don't know about the default settings on all distros. :-)
    – Paul Gear
    Aug 2 at 23:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .