When the a system loses power and has no CMOS/RTC battery, time can go backwards. Loss of time can cause issues with NTS certificate checks (as documented in #1428) but going backwards in time can wreak havok across the system, causing timers/cron jobs to start when they shouldn't, backups to run at the wrong time, etc.
As of systemd/systemd#20142, systemd-timesyncd:
- Periodically (and after every sync) saves the current time to
/var/lib/systemd/timesync/clock.
- On start, it restores this time if the time reported by the RTC is in the past (relative to this file).
- The
systemd-timesyncd.service unit is ordered before time-set.target and only reports that it is "ready" after it restores this time. This prevents delays timers from running until the time has been restored.
It would be great if ntpd-rs could do the same thing.
This can just as easily be done as a separate bash script, but solving this within ntpd-rs would be a step towards fixing #1428 (it would let ntpd-rs detect when time has gone backwards).
When the a system loses power and has no CMOS/RTC battery, time can go backwards. Loss of time can cause issues with NTS certificate checks (as documented in #1428) but going backwards in time can wreak havok across the system, causing timers/cron jobs to start when they shouldn't, backups to run at the wrong time, etc.
As of systemd/systemd#20142,
systemd-timesyncd:/var/lib/systemd/timesync/clock.systemd-timesyncd.serviceunit is ordered beforetime-set.targetand only reports that it is "ready" after it restores this time. This prevents delays timers from running until the time has been restored.It would be great if ntpd-rs could do the same thing.
This can just as easily be done as a separate bash script, but solving this within ntpd-rs would be a step towards fixing #1428 (it would let ntpd-rs detect when time has gone backwards).