| NTP and/or clock issue | Matthew Wyenandt | 27/04/18 08:12 | Hi all, I'm new to Qubes 4.0 and loving it. I'm having an odd situation where the time on my clock is showing -5 from my current timezone, rather than -5 from UTC. For instance, I'm physically located in America/Chicago timezone, which is -5 UTC. My Qubes OS clock is set for America/Chicago timezone, which also says -5 UTC; however, the clock is now showing -10 UTC. I've tried to figure out a way to manipulate the clock within dom0, but I'm not finding anyway to do so. |
| Re: [qubes-users] NTP and/or clock issue | Ivan Mitev | 27/04/18 08:46 | Hey,
your hw clock is likely set to local time instead of UTC ; this usually happens because you use(d) MS Windows. `hwclock` allows you to tweak the hardware clock; you can manually set the time and then run `hwclock --systohc --utc`, that should fix your problem. Note that `qvm-sync-clock` is run every hour in dom0 and should fix the offset automatically: it first syncs dom0's time with the time in "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and it then runs `hwclock --systohc`. If you still have issues, check that the timezone and time are OK in sys-net (or whatever clockvm you have defined). |
| Re: [qubes-users] NTP and/or clock issue | Matthew Wyenandt | 27/04/18 11:34 | Thanks for this info, Ivan. I followed these steps. Should my sys-net clock be set for UTC? When I run hwclock --show, it's still showing EDT as the current time. Do I need to set this manually? I would prefer that it get updated via ntp. |
| Re: [qubes-users] NTP and/or clock issue | Ivan Mitev | 27/04/18 12:32 | The clockVM's clock is synchronized with NTP, you don't need to set
anything manually... Clock synchronization works like that (if I'm not mistaken): 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh` script sets the VM's timezone (the script gets the timezone from dom0 with `qubesdb-read /qubes-timezone`). 2a- if the VM is defined as the clockVM (sys-net by default) then the `systemd-timesyncd` service synchronizes the VM's clock with NTP. 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with the time in clockVM (sys-net). So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago). Then the easiest way is to perform a *full* reboot and everything should be fine. If it isn't, you'll have to debug a bit further: - make sure the timezone is OK in VMs too (again with `ls -l /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone` returns: it should be the same as dom0's timezone. - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl status systemd-timesyncd` should output a line like Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)." the clock in sys-net should show the right time (both `date` and `sudo hwclock` should show the same time, with the EDT format). - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time should then be OK. Hope this helps ! |
| Re: [qubes-users] NTP and/or clock issue | Matthew Wyenandt | 27/04/18 13:20 | Okay, so something doesn't seem to be configured correctly. During further debugging, i was able to get the correct timezone using 'timedatectl set-timezone Americas/Chicago'. However, when running 'systemctl status systemd-timesyncd' I get the following output:
systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; v Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d └─30_qubes.conf Active: inactive (dead) Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago └─ ConditionPathExists=/var/run/qubes-service/clocksync was not met Docs: man:systemd-timesyncd.service(8) It seems the clocksync file is missing from /var/run/qubes-service/ directory. |
| Re: [qubes-users] NTP and/or clock issue | Ivan Mitev | 27/04/18 20:28 | If the output above is for your clockVM (sys-net) then something isn't
right. Otherwise that's the standard output for other VMs: /var/run/qubes-service/clocksync is set only in the clockVM I'm afraid I can't help more than that - maybe someone more experienced will chime in, otherwise you should file an issue. just in case, please paste the output of the following commands: in dom0: - `timedatectl` - `ls -l /etc/localtime` in sys-net: - `systemctl restart systemd-timesyncd` followed by `systemctl status systemd-timesyncd` - `timedatectl` - `qubesdb-read /qubes-timezone` in another VM: - `sudo qvm-sync-clock` - `timedatectl` - `qubesdb-read /qubes-timezone` |
| Re: [qubes-users] NTP and/or clock issue | Matthew Wyenandt | 28/04/18 05:47 | Okay, so I read through the man pages of hwclock and timedatectl and finally got this resolved.
Ivan, you were correct that my hwclock in bios was set to localtime, throwing everything off. I set that to UTC. I then reviewed your first two posts and set dom0 to point to the correct timezone. I then set hwclock in clockvm to be utc. Then reboot. All is correct and times are displaying correctly. I think I was making everything too complex when I was reading your posts, I apologize. steps I took to correct the problem: Dom0: 'sudo rm /etc/localtime' 'sudo ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime' clockvm (sys-net): 'sudo hwclock --systohc --utc' reboot computer now in both dom0 and clockvm 'ls -l /etc/localtime' points to the correct timezone and 'timedatectl' shows correct UTC and Local time as well as time zone. Thanks again for your help, it took some time, but I learned a lot about the interaction between Dom0 and the other VM's. |
| Re: [qubes-users] NTP and/or clock issue | Ivan Mitev | 28/04/18 07:26 | Hi Matthew,
Glad that you solved it ! No need to apologize - I'm happy to help. Well, we wouldn't be learning if everything was always working as planned ! To be frank I also learned a few things here too and this whole thread will likely be useful to other people. Maybe I'll even transform it into a prettier doc... Cheers, Ivan |