Re: [chrony-users] Question about chrony use in a system without RTC battery

[Kris van Rens <kris.van.rens@xxxxxxxxxxx>]

Hi all,

Thanks very much for all the detailed responses! I really appreciate
it -- the online community is just awesome :-)

A couple of answers to questions I got:

On Wed, Mar 9, 2022 at 5:08 PM Daniel Gearty <dpgearty@xxxxxxxxxxxx> wrote:
>
> These two considerations may not apply but I will state them anyway:
>
> 1) NTP synchronizes UTC.  Local time offsets are handled by the operating
> system.  You would need to set the appropriate OS variables so that your
> data time is consistent year-round.  Otherwise, the time may SPRING forward
> and FALL back from daylight saving time.

Yes, we only use UTC in all our systems. The leap seconds are
considered 'noise' and can be dealt with.


> From: Bill Unruh <unruh@xxxxxxxxxxxxxx>

> Without an rtc it is impossible to have a monotonic time across power
> losses, at least for the first little while. If you are willing to wait a
> little while
> (minutes/seconds) chrony can reset the clock to a reasonable value (within
> seconds or milliseconds of UTC, assuming you have access ( internet or local
> time source). Eg, use the burst and the makestep directives. Note that
> setting the clock to 2050 will produce a step back in time to get to the
> right time, so that is of no help.
> Make sure that nothing that depends on monotonic time is started before
> chrony has been operating and has set the "right " time to within you
> tolerances.

At this moment 'automatic' jumps back in time due to a failing RTC are
the most important problem to be tackled. The power/internet outages
we experience are assumed to be temporary (say max. a few days).

The current solution I'm implementing assumes that at one point the
system is able to get an NTP synchronization to start with. From that
point onward a periodic job tests if NTP synchronization is active and
if so: touches the chrony drift file which then can be taken as the
time source of truth. At boot time (before Chrony) a check will be
done if the RTC is (far) behind this time, if so force the time to be
this last set time. From there at some point the actual NTP
synchronization is assumed to be picked up at some point in time
correcting for the outage time (assumed to be a forward jump in time).


> > ---
> > $ cat /etc/default/chronyd
> > export OPTIONS='-s -r'
>
> Why not just change the system service file to include those options for
> running chronyd?

Good question, but this integrates nicely with Yocto. We now add a
file (/etc/default/chronyd) whereas otherwise we'd have to override
the .service file entirely, or run a sed command to replace the
$OPTIONS value. All are fine solutions I guess.


> Why would you break the internet connections. Is that what actually happens
> in a powerloss-- the internet goes down for an hour or so first and then the
> power loss occurs. And the internet only comes up long after? If not, why is
> this your test?

We test many scenarios, as we've seen almost all permutations in the
field. But the scenario of internet going down, then a power outage,
power recovery without internet seems like one of the most worst-case
ones.

Again, thanks for the help, I will report back if I have any more
question or got it working.

Have a nice day, best regards,

Kris

-- 
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.