This problem occurs because of a conflict between ntp.service
and systemd-timesyncd.service
. It's a known bug.
Why does this happen? It occurs on systems that have been upgraded to 19.10. ntp.service
is carried over during an upgrade, and 19.10's systemd-timesyncd.server
won't start in its presence.
more /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService
See the following:
systemctl status ntp.service
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enab
Active: active (running) since Wed 2020-01-15 11:05:12 PST; 1h 21min ago
Docs: man:ntpd(8)
Main PID: 28740 (ntpd)
Tasks: 2 (limit: 4915)
Memory: 2.0M
CGroup: /system.slice/ntp.service
└─28740 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 120:131
Jan 15 11:15:30 Satellite-E55 ntpd[28740]: 184.105.182.7 local addr 192.168.0.10
Jan 15 11:16:28 Satellite-E55 ntpd[28740]: 198.58.105.63 local addr 192.168.0.10
Jan 15 11:17:38 Satellite-E55 ntpd[28740]: 69.10.161.7 local addr 192.168.0.100
Jan 15 11:17:39 Satellite-E55 ntpd[28740]: 66.172.17.62 local addr 192.168.0.100
Jan 15 11:28:55 Satellite-E55 ntpd[28740]: 172.98.193.44 local addr 192.168.0.10
Jan 15 11:28:57 Satellite-E55 ntpd[28740]: 45.33.2.219 local addr 192.168.0.100
Jan 15 11:29:20 Satellite-E55 ntpd[28740]: 91.189.94.4 local addr 192.168.0.100
Jan 15 11:29:55 Satellite-E55 ntpd[28740]: 216.229.0.49 local addr 192.168.0.100
Jan 15 11:31:07 Satellite-E55 ntpd[28740]: 74.6.168.73 local addr 192.168.0.100
Jan 15 11:31:08 Satellite-E55 ntpd[28740]: 69.195.142.11 local addr 192.168.0.10
systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vend
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
Jan 15 07:52:09 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:52:11 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:52:13 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:52:23 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:52:24 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:52:57 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:52:58 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:53:00 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:54:00 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
Jan 15 07:59:57 Satellite-E55 systemd[1]: Condition check resulted in Network Ti
One visual side effect of this problem can be seen in the Date & Time
settings panel. You can't enable "Automatic Date & Time". The switch flips back to disabled.
However, ntp
still does the time synchronization with the various ntp servers.
This can be fixed by uninstalling ntp
, ntpdate
, and sntp
, and letting systemd-timesyncd.service
perform the time synchronization.
Sources:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1858095
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1848309
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849156
timedatectl set-ntp 1
maybe then followed bytimedatectl timesync-status
andsystemctl status systemd-timesyncd
. There are environments (e.g. in containers) where the service will just not start due to the condition of being in a container. That should be in that data, therefore reporting such info here by updating the question might also help