Syncing clock with ntp

[John Maher]

I have always had a problem with my system clock losing time. My understanding is that the ClockVM, which is usually sys-net, runs ntp and and communicates the time to dom0, which communicates the time to all of the other VMs.

I don't know exactly what makes sys-net the ClockVM, but I noticed that it was not running the service clocksync (I noticed this service in sys-net of a different machine), so I added clocksync as a service to sys-net of the problem machine.

I assumed ntp would be running on sys-net, but it was not. And when I checked the other system (which already had clocksync as a service), I see that it too does not have ntp running.

I don't know how sys-net will get network time without ntp running.

Any suggestions on how to get my clock synced with network time?

Thanks.

John

[dhorf-hfre...@hashmail.org]

On Fri, Dec 27, 2019 at 11:51:25AM -0800, John Maher wrote:
> understanding is that the ClockVM, which is usually sys-net, runs ntp and
> and communicates the time to dom0, which communicates the time to all of
> the other VMs.

actualy in qubes4 dom0+appvms "fetch" the time from clockvm,
though appvms go through dom0 for that (qrpc acl plus an extra
check that clockvm is running).
(in qubes3 it used to be dom0 pulling from clockvm, then pushing
to all appvms, which had the side-effect that a naughty appvm
could block/stall the clocksync mechanism for all appvms)

> I don't know how sys-net will get network time without ntp running.

man systemd-timesyncd

> Any suggestions on how to get my clock synced with network time?

if your clock is off, check clockvm (sys-net) first, and make sure to
get systemd-timesyncd.service working there.
once clockvm has a reasonable time, it should filter down to "all"
other VMs on its own over the next 6 hours or so.
you can speed up the transfer from clockvm to all other vms by
running "sudo qvm-sync-clock" in each vm you want to fetch time.

note the current resolution for the sync mechanism is just "seconds",
which even means it can cause the time to run "backwards" when triggered
at the wrong moment.
(i have a patchset somewhere to improve this to "low ms" precision, if
anyone cares...)