On Fri 28 Jun 2024 at 15:05:34 (-0500), John Hasler wrote: > David writes: > > With chrony, you can monitor the RTC over time and adjust the system > > clock in accordance with its drift rate at boot time, without > > correcting the RTC itself, or you can actually set the RTC from the > > system clock periodically. > > That leads to the probelem that started this thread: system time being > set incorrectly at boot and then stepped later. > > > > The particular problem at shutdown is that there were/are systems, as > > you described, that write the system time to the RTC without > > necessarily regarding how you might be running the clock otherwise. > > That alteration is unknowable for chrony when it restarts after > > booting. > > Obviously you must make sure that only one process ever writes to the > RTC. > > Actually you need never write to the RTC at all: just track its offset > and drift rate. That would require hacking the boot process to make > sure only your code ever reads it, though.
I think that's what I wrote in the first half of the sentence at the top. I don't think you can avoid the kernel setting the system clock before chrony does, but I don't see the problem with that: chrony just sets it again when it runs. So the problem may reduce to how to get resume to run chrony (as the example) before any user processes run again. There are options to make that more likely, like keeping chrony resident, and increasing its scheduling priority, and I have already suggested a method that might allow systemd to make it certain. Cheers, David.
