On Mon, Oct 05, 2015 at 06:20:47PM +0200, Miroslav Lichvar wrote: > On Mon, Oct 05, 2015 at 10:25:54AM +0100, Nuno Gonçalves wrote: > > - Check that the RTC is more in the past than what can be accounted > > for DST or Timezone changes. If RTC<driftfile-26h, restore from > > driftfile. > > Ok, that's an interesting idea. Maybe make the interval even longer, > say 1 year to have some room for other sources of errors?
I have some code ready for this, but I realized if there is some interval in which the driftile timestamp is ignored, it will not work when the chrony RTC tracking (rtcfile) is enabled. When the RTC time is reset to its initial value and corrected by the previously measured offset, it may still be in the allowed interval before the driftfile modification time and it will be ignored. It would be basically restoring time of the previous boot. I'm not sure if we can make any assumptions on the raw RTC time if rtcfile is enabled, it's perfectly ok to keep it in 1970 and rely on chrony to correct the offset. So, should we always restore time from the modification timestamp of the driftfile with -s if it's in future and log a warning when the RTC time is ignored to make it easier for the user to debug any unexpected behavior? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
