Architecture
Timezone
The system’s timezone is set in dom0.
VMs can read the system’s timezone value from dom0 through the QubesDB qubes-timezone key. On Linux VMs with qubes-core-agent installed the time zone is set at boot time by the /usr/lib/qubes/init/qubes-early-vm-config.sh script.
Clock synchronization
“ClockVM”
One of the VMs is defined globally as “clockVM”, from which other VMs and dom0 will synchronize their clock with. The following command in dom0 shows which VM has this role:
qubes-prefs clockvm
By default the clockVM is sys-net. Its clock is synchronized with remote NTP servers automatically by the systemd-timesyncd service.
The clockVM has the clocksync Qubes service enabled (as shown by qvm-service or in the Services tab in sys-net Qubes Setting GUI). This allows various scripts and systemd service definitions to test for the presence (or lack thereof) of /var/run/qubes-service/clocksync to differentiate the clockVM from other VMs. This in turn allows the clockVM to be based on the same template that other VMs use.
VMs (other than ClockVM)
Clock synchonization happens:
- at boot time (
qubes-sync-timesystemd service) - after suspend (
/etc/qubes/suspend-post.d/qvm-sync-clock.sh) - every 6 hours (
qubes-sync-time.timersystemd timer)
Those scripts run /usr/bin/qvm-sync-clock which uses the qubes.GetDate RPC call to obtain the date from the clockVM and run /usr/lib/qubes/qubes-sync-clock to validate the data received and set the date.
Dom0
Clock synchonization in dom0 is done by the /etc/cron.d/qubes-sync-clock.cron cron job every hour, which calls /usr/bin/qvm-sync-clock. Note that despite having the same name the qvm-sync-clock script in dom0 is different from the one installed in VMs; however it performs the same actions - using the qubes.GetDate RPC call, input validation and setting the date.
Tweaking time synchronization defaults
VMs
(Re)setting the clock every 6 hours might not be accurate enough for some software. There are basically two ways to improve it:
- disable the timer and run a ntp client; that is the best solution for time accuracy but it increases the attack surface considerably.
- change the definition of the systemd timer so that it’s run more frequently.
The latter is simply a matter of putting the following definition in /etc/systemd/system/qubes-sync-time.timer:
[Timer]
OnUnitActiveSec=10min
Doing so overrides the relevant definitions in /usr/lib/systemd/system/qubes-sync-time.timer and prevents the changes from being overwritten by the next qubes-core-agent-systemd package upgrade.
To test, reload the definitions with sudo systemctl daemon-reload and check the timers’ status with systemctl list-timers.
If you want those changes to stick after a reboot, apply them in the TemplateVM you’re using for your AppVM; alternatively you could put the systemd definition file in to your AppVM’s /rw/config folder and use the /rw/config/rc.local script to copy the definition file to /etc/systemd/system/qubes-sync-time.timer and issue a systemctl daemon-reload command.
Dom0
Simply change the cron “frequency” in /etc/cron.d/qubes-sync-clock.cron. This might not survive updates of the qubes-core-dom0-linux package though. If that’s the case, one could add a cron job that runs qvm-sync-clock more often, in addition to the original /etc/cron.d/qubes-sync-clock.cron cron job.
Debugging problems
Time off by X hours
A common issue is to have the time off by a number of hours. There are usually two causes:
- Wrong configured timezone.
- MS Windows was used before installing Qubes OS (or in the case of dual-boot installations). Windows stores the time in the hardware clock as “local time” while Linux stores the time as UTC.
To check that the timezone is OK in dom0, run timedatectl. Alternatively, look at the /etc/localtime symlink: it should point to a timezone in /usr/share/zoneinfo. If you need to change the timezone in dom0, you can use
sudo timedatectl set-timezone "Australia/Queensland"
or
sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/Australia/Queensland /etc/localtime
To set the system’s hardware clock to UTC, run the following command in the clockVM (usually sys-net):
sudo hwclock --systohc --utc
Then the easiest way to have the changes applied to all VMs is to do a full reboot.
Wrong time/date
It is also possible that the clockVM’s clock isn’t properly synchronized with remote NTP servers. Check the status of the systemd-timesyncd service with systemctl status systemd-timesyncd in the clockVM (usuall sys-net):
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
└─30_qubes.conf
Active: active (running) since Sun 2018-04-29 06:59:59 EEST; 1 weeks 1 days ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 16966 (systemd-timesyn)
Status: "Synchronized to time server 95.87.227.232:123 (0.fedora.pool.ntp.org)."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/systemd-timesyncd.service
└─16966 /usr/lib/systemd/systemd-timesyncd
In the output above, the clock was successfully synchronized with the 0.fedora.pool.ntp.org server. The output might be empty if logs were rotated though, in that case restart the service with systemctl restart systemd-timesyncd and recheck its status.
No clock synchronization usually means the clockVM has a problem with networking.
This document was migrated from the qubes-community project
- Page archive
- First commit: 07 May 2018. Last commit: 20 Sep 2018.
- Applicable Qubes OS releases based on commit dates and supported releases: 3.2, 4.0
- Original author(s) (GitHub usernames): taradiddles
- Original author(s) (forum usernames): @taradiddles
- Document license: CC BY 4.0