Score:1

systemd-timesyncd Inactive at boot ubuntu 20.04

dk flag

First off I've searched for the answer here and it's not the standard disable/purge ntp/chrony. I can run dpkg -l | grep ntp and dpkg -l | grep chrony and neither returns anything, so I know it's not a conflict with that. It's also a fresh vagrant image of ubuntu 20.04 that has no cruft leftover from ugprading from a previous version of ubuntu.

With systemd-timesyncd enabled, at bootup it fails to start and sync time.

    systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-timesyncd.service(8)

There are no conditionals that should block it in /lib/systemd/system/systemd-timesyncd.service, and it's all defaults

[Unit]
Description=Network Time Synchronization
Documentation=man:systemd-timesyncd.service(8)
ConditionCapability=CAP_SYS_TIME
ConditionVirtualization=!container
DefaultDependencies=no
After=systemd-sysusers.service
Before=time-set.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-set.target time-sync.target

[Service]
AmbientCapabilities=CAP_SYS_TIME
CapabilityBoundingSet=CAP_SYS_TIME
ExecStart=!!/lib/systemd/systemd-timesyncd
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectKernelLogs=yes
ProtectSystem=strict
Restart=always
RestartSec=0
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
RuntimeDirectory=systemd/timesync
StateDirectory=systemd/timesync
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service @clock
Type=notify
User=systemd-timesync
WatchdogSec=3min

[Install]
WantedBy=sysinit.target
Alias=dbus-org.freedesktop.timesync1.service

/etc/systemd/timesyncd.conf only has the following

[Time]
NTP=0.us.pool.ntp.org
FallbackNTP=ntp.ubuntu.com 1.us.pool.ntp.org time.cloudflare.com

But when I manually start it with systemctl restart systemd-timesyncd it works just fine, it only gets into the dead state at bootup.

systemctl restart systemd-timesyncd
systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-07-29 20:34:51 UTC; 6s ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 1347 (systemd-timesyn)
     Status: "Initial synchronization to time server 23.175.208.10:123 (0.us.pool.ntp.org)."
      Tasks: 2 (limit: 2320)
     Memory: 1.3M
     CGroup: /system.slice/systemd-timesyncd.service
             └─1347 /lib/systemd/systemd-timesyncd

I can even put systemctl restart systemd-timesyncd into rc.local and it works on bootup after rc.local runs. I could go that route and call it good, but it definitely should be working without that. I can't find any indication of failures in /var/log/syslog, either.

If it matters, this is a virtualbox vm, but I need to set this up on ec2 eventually.

Jesse Lee avatar
dk flag
As I said at the beginning, dpkg -l | grep ntp returns nothing so it is not conflicting with systemd-timesyncd.
Sylvain Bourdette avatar
ao flag
Any news? I have the same problem on my ubuntu 20.04 vm Systemd-timesyncd seems to start and stop just like if we asked him Jul 10 22:43:09 bdd systemd[1]: Stopping Network Time Synchronization... Jul 10 22:43:09 bdd systemd[1]: systemd-timesyncd.service: Succeeded. Jul 10 22:43:09 bdd systemd[1]: Stopped Network Time Synchronization. I found the explanation : https://stackoverflow.com/questions/67511592/debugging-systemctl-inactive-dead But I don't know how to solve it
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.