| Re: [chrony-users] Fwd: Chrony malfunctioning at beaglebones |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, Oct 05, 2015 at 10:25:54AM +0100, Nuno Gonçalves wrote:
> I don't think using the compile time is required, and would introduce
> a compile dependent behavior, I would prefer to use a magic number.
FWIW, there already is a compiled-in constant based on build time. The
NTP era assumed by chronyd starts by default 50 years ago. This is
needed to convert NTP timestamps correctly after 2036 and the 50 year
offset was chosen so it will stay below 1970 in the near future. When
it will reach 1970, chronyd as an NTP client will jump to 2106 when
synchronized to an NTP server that has no RTC and is stuck in 1970.
I'm not sure how much of a problem that really is.
> We could:
>
> - Check for a known wrong date (I would select 2015-01-01 for the
> magic number, since there is no advantage of using any other in the
> past). If RTC<2015-01-01<driftfile, restore from driftfile.
This date could be hardcoded in the source code and updated
occasionally, or it could be set by the make_release script to the
current date.
But can we safely assume noone needs to keep time in the past, for
instance to workaround a bug in some unsupported software?
And if we could add such check for the RTC, could we check also time
received from NTP servers and refuse to go in the past?
> - 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?
--
Miroslav Lichvar
--
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.