Re: [qubes-users] NTP and/or clock issue
Hi Matthew, On 04/28/2018 03:47 PM, Matthew Wyenandt wrote: > On Friday, April 27, 2018 at 10:28:04 PM UTC-5, Ivan Mitev wrote: >> On 04/27/2018 11:20 PM, Matthew Wyenandt wrote: >>> On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: >> Hey, >> >> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: >>> 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. >> >> 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). > > 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. 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 ! >>> >>> 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. >> >> >> 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
Re: [qubes-users] NTP and/or clock issue
On Friday, April 27, 2018 at 10:28:04 PM UTC-5, Ivan Mitev wrote: > On 04/27/2018 11:20 PM, Matthew Wyenandt wrote: > > On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: > >> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > >>> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: > Hey, > > On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > > 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. > > 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). > >>> > >>> 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. > >> > >> 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 ! > > > > 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. > > > 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: > -
Re: [qubes-users] NTP and/or clock issue
On 04/27/2018 11:20 PM, Matthew Wyenandt wrote: > On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: >> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: >>> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: Hey, On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > 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. 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). >>> >>> 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. >> >> 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 ! > > 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. 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` -- You received
Re: [qubes-users] NTP and/or clock issue
On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: > On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > > On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: > >> Hey, > >> > >> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > >>> 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. > >> > >> 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). > > > > 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. > > 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 ! 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3da0d854-ee68-4534-b575-8e082d5b8f67%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP and/or clock issue
On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: >> Hey, >> >> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: >>> 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. >> >> 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). > > 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. 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 ! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ce64581a-8d69-1cd0-8fcf-2bceaf0c21db%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP and/or clock issue
Hey, On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > 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. 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). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/224371b5-528d-c40a-8b09-375a73940441%40maa.bz. For more options, visit https://groups.google.com/d/optout.
