Root Causes of Clock Sync Issues?

Since upgrading the dom0 time keeps getting out of sync by a few seconds to a minute or so.

Common fixes I’m finding on the forum aren’t resolving it:

In the offline qubes clocksync is set as a service.

In the online qubes clocksync is set as a service in sys-net.

I’ve also tested setting clocksync as a service in both the online qube and sys-net.

systemctl restart systemd-timesyncd & qvm-sync-clock don’t seem to do anything. No errors show when running the commands, yet the time doesn’t update to current time.

The only fix has been to manually set the clock. But it quickly gets out of sync.

Problem seems to have started since the re-install/update to 4.1.2.

Anyone else seeing similar and/or found a fix outside of manually setting the clock?

Sounds similar to what I was facing recently. Though, my solution was installing systemd-timesyncd to my clock qube template (which is sys-net):

2 Likes

It shouldn’t be. The main purpose of the clocksync Qubes service is to signal to a VM that it is the ClockVM. Setting a VM as the ClockVM will automatically enable it on that VM. For other VMs, it should usually be neither explicitly enabled nor explicitly disabled but reset to its default, using the “Remove service” button in the Services tab of Qube Settings or using qvm-service --default VMNAME clocksync

Specifically, what an enabled clocksync Qubes service does is

  • allow systemd-timesyncd.service to start (assuming that the VM uses this systemd service, and also isn’t otherwise configured to prevent its startup - e.g. Whonix has a different network time sync mechanism)

  • prevent qubes-sync-time.service and the related .timer from starting, so that the VM doesn’t get its time from the ClockVM (which would be through qrexec btw, meaning it works even if the VM that’s talking to the ClockVM is offline)

4 Likes