systemd-timesyncd service is running in idle and doesn't synchronize time

Question

I'm trying to synchronize time on my Intel NUC that is running Ubuntu 16.04.3 LTS with an NTP server that is running on a Windows PC.

I already checked that the NTP server is running correctly.

It seems to me as if the service doesn't read from the config file /etc/systemd/timesyncd.conf

Output of timedatectl status

      Local time: Wed 2019-01-16 21:32:01 CET
  Universal time: Wed 2019-01-16 20:32:01 UTC
        RTC time: Wed 2019-01-16 20:32:01
       Time zone: Europe/Vienna (CET, +0100)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

Output of systemctl status systemd-timesyncd right after systemctl restart systemd-timesyncd

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor pr
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Wed 2019-01-16 21:36:08 CET; 11s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 2316 (systemd-timesyn)
   Status: "Idle."
   CGroup: /system.slice/systemd-timesyncd.service
           └─2316 /lib/systemd/systemd-timesyncd

Jan 16 21:36:08 coretv systemd[1]: Starting Network Time Synchronization...
Jan 16 21:36:08 coretv systemd[1]: Started Network Time Synchronization.

My config file in /etc/systemd/timesyncd.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
NTP=192.168.20.1
#FallbackNTP=ntp.ubuntu.com

If it changes anything, all commands are run as root over an ssh connection.

Is there something I'm missing?

Edit:

I don't have time to play around with this issue anymore. I will use a workaround on my end so I don't have to rely on the system time.

Answers are still appreciated since fixing this would be a much cleaner solution.

You can try ntpd instead of timedatectl: https://askubuntu.com/a/1046217/231142 In the ntp.conf file you would put server 192.168.20.1 — Terrance, Jan 16 '19 at 14:17
@Terrance I could if I had a way to download the package. This is my only Ubuntu machine and it doesn't have access to the internet. — Matthias, Jan 16 '19 at 15:08
Try the second answer below mine in the linked answer I put there. If not, you probably will have to find a temporary way to get internet on it, or try many number of offline ways to get other applications installed into your Ubuntu. https://askubuntu.com/questions/974/how-can-i-install-software-or-packages-without-internet-offline — Terrance, Jan 16 '19 at 15:38

score 6 · Answer 1 · answered May 22 '20 at 16:59

I realize this is an old thread, but recently I had the exact same problem and I want to share my solution so others can avoid spending hours trying to figure it out.

The problem for me turned out to be the RootDistanceMaxSec parameter in timesyncd.conf. The default is 5 seconds; however, when looking at the NTP packets in Wireshark, the root dispersion value was around 10 seconds. I believe systemd-timesyncd was ignoring all the NTP packets because the root dispersion value was above the maximum.

To solve the problem, I modified timesyncd.conf by uncommenting the line that starts with RootDistanceMaxSec and updated the value to a number that was a few seconds greater than the root dispersion value I was seeing in the NTP packets. I then restarted my system and everything worked perfectly.

Hopefully this helps someone out there save a few hours.

On my Ubuntu 19.10, I uncommented and change it to 55, restarted systemd-timesyncd.service and it works! — chehsunliu, Jul 04 '20 at 13:46
Changed mine to 15, solved it as well. 5 seconds seems like more than enough time (for my simple network), perhaps when initially syncing the skew is too great? — Tyler Montney, May 30 '22 at 18:39

systemd-timesyncd service is running in idle and doesn't synchronize time

Edit:

1 Answers1