On 2018-09-20 13:04, unman wrote: > On Wed, Sep 19, 2018 at 07:50:59PM -0700, Gaijin wrote: >> On 2018-09-19 07:36, Ivan Mitev wrote: >> > On 9/19/18 9:22 AM, Gaijin wrote: >> >> On 2018-09-19 05:22, Ivan Mitev wrote: >> >>> On 9/19/18 5:17 AM, Gaijin wrote: >> >>>> Running Qubes R3.2 >> >>>> >> >>>> I have some software that I run in an AppVM that needs to be accurate to >> >>>> within a second or two of NTP server time in order to work. I have >> >>>> finally figured out how to get my ClockVM to sync to an NTP server and >> >>>> for timesyncd.service to run when sys-net boots. >> >>>> >> >>>> My problem is that my AppVM slowly loses several seconds after some >> >>>> time, and I can't figure out a way to manually or automatically force it >> >>>> to resync itself. >> >>> >> >>> I don't have a R3.2 to test, but if it's like R4 your VM has a systemd >> >>> timer that updates the time every 6 hours [1]. In that case you could: >> >>> - change the definition of the timer so that it's run more frequently >> >>> - disable the timer and run a ntp client ; that'll be the best solution >> >>> if your software is very time sensitive, but it increases the attack >> >>> surface because of the ntp client. >> >>> >> >>> >> >>> [1] >> >>> https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md >> >> >> >> How might I adjust the schedule of qubes-sync-time.timer in the AppVM if >> >> that is available in R3.2? That looks like a safer way to proceed if >> >> possible. >> > >> > Provided that R3.2 time sync mechanism is the same as R4, you could >> > paste the following text into /etc/systemd/system/qubes-sync-time.timer: >> > >> > [Timer] >> > OnUnitActiveSec=10min >> > >> > >> > Doing so allows you to override stuff from >> > /usr/lib/systemd/system/qubes-sync-time.timer and preverve your changes >> > in case the original unit file is updated. >> > >> > Then reload the definitions with `sudo systemctl daemon-reload` >> > >> > You can see the timer's 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 add the >> > new file to your AppVM's /rw/config and issue commands in the rc.local >> > script there (copy the file + reload systemd). >> >> Looks like this would be easier in R4. The 3.2 doesn't have the >> qubes-sync-time.timer or perhaps it's named something else. Would anyone >> know which file might control this in 3.2? Or is there a way to make a >> systemd timer in an AppVM to force Qubes to resync with the NTP server? >> > > In 3.2 time synchronizing was somewhat different, so the advice re 4.0 > doesn't help. > You should not have needed to do anything special to the clockVM to get > time syncing working there. Almost certainly you should revert those > changes. > I recall there was a cron job running every 6 hours : I believe > you can find the cron file under /etc/cron.d in dom0 > You could try changing the cron job to make the timer reset more > regularly. > > You haven't said what period you are seeing the time drift occur, but > change the frequency to something that preempts the drift without > constantly firing off. > > Remember this is undoubtedly going to help fingerprint your system. > > unman
What I had to do special in the ClockVM to get it working (Fedora 28 minimal) was to follow the instructions here https://github.com/QubesOS/qubes-issues/issues/3983 as systemd-timesyncd wasn't starting. I have that working and the time syncing in the ClockVM seems to be OK. My time drift comes in my AppVM (Fedora 28). Right now it's about 2 seconds off after running overnight. In that the systemd-timesyncd.service is not active. I thought the ClockVM was supposed to control the time in the other VMs, so I haven't changed that. I found the qubes-sync-clock.cron and switched it from 6 hours to 3 hours and I'll leave the AppVM running to see if the drift fixes. -- 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/edc8ea2b3758882ac2c2a856515eb5cc%40riseup.net. For more options, visit https://groups.google.com/d/optout.
