[CAUTION: Non-UBC Email]
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.