|Re: [chrony-users] Fwd: Chrony malfunctioning at beaglebones|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
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
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.