Re: Question about chrony use in a system without RTC battery

Why not just use the prodedure that both Miroslav and I suggested-- run a cron
job once a minute to touch /var/log/chrony.drift. That should be pretty
reasonable even if the internet went down for a couple of hours before the
power outage. Most of the computer clocks do pretty well freewheeling, so that
time should not be too far out  (less than a second and certainly not fast by
a minute ) for use when chrony comes back up again and the internet comes up
at powerup so that the count is progressive. I would also make sure that that
program which dies if the time ever goes backwards  starts up a few minutes
after chrony comes up again. 
Note also since your program presumably writes out files, you could use the
timestamp on those files instead of chrony.drift as the source for you time at
bootup.

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ [email protected]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Thu, 10 Mar 2022, Kris van Rens wrote:

> [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-A7wQCf4NAVlWk0Htik3J/[email protected]> 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 <[email protected]>
>
>> 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-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "unsubscribe" in the subject.
> For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "help" in the subject.
> Trouble?  Email [email protected]
>
>

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]