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

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


On Wed, 9 Mar 2022, Kris van Rens wrote:

> [CAUTION: Non-UBC Email]
>
> Hello!
>
> I have a question regarding Chrony use in (Yocto-based) systems that
> have no RTC battery, or at least a very short-lived one. The devices
> I'm working with regularly have unstable internet connections, and
> sometimes lose power all of the sudden (clearing the RTC value).
>
> My main goal is to prevent the system time to jump back. My
> application data recording mechanism assumes time to increase
> monotonously, and a jump back in time will prevent my application from
> writing any data. In a case of a temporary poweroff + RTC value loss,
> I'd rather have an erroneous time indication that disregards the
> outage time, but at least does not jump back in time. In any normal
> situation NTP is always enabled and the internet connection is stable,
> but power outages do happen.
>
> I've been testing with Chrony which seems like the right tool for the
> job. The NTP synchronization works really well, but I can't seem to
> get the power loss situation covered well.
>
> My /etc/chrony.conf looks like this:
>
> ---
> include /etc/chrony.d/00-custom.conf
>
> pool 0.pool.ntp.org iburst
> pool 1.pool.ntp.org iburst
> pool 2.pool.ntp.org iburst
> pool 3.pool.ntp.org iburst
>
> makestep 1.0 3
> driftfile /var/lib/chrony/drift

You have no rtc so why are you giving the rtcfile directive?

> rtcfile /var/lib/chrony/rtc
> rtcautotrim 1
> dumpdir /var/lib/chrony
> logdir /var/log/chrony
> log tracking
> ---
>
> The extra configuration file '/etc/chrony.d/00-custom.conf' is empty
> for now, but lives in persistent memory, the root filesystem is
> readonly. Of course /var is writable too.
>
> I'm using systemd as the startup management system, and have chronyd
> set to start up with "-s -r":

> ---
> $ cat /etc/default/chronyd
> export OPTIONS='-s -r'

Why not just change the system service file to include those options for
running chronyd?

> ---
>
> This will pass the $OPTIONS to the system service file. But I don't
> really know how to verify this.
>
> My observation with power loss simulations is that the system keeps on
> jumping back in time (~a week). What I do is I break the internet
> connection such that the NTP synchronization is lost, then pull the
> power plug, re-insert the power plug (but leave the internet
> connection broken). As far as I could read in the documentation,

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?

> Chrony should be able to pick up the last modification time from the
> driftfile, but this file is not always there. Is there some other way

Well, you could set things up to it is there-- if nothing else set up a cron
job to touch the file every minute.
> to force resetting the time at boot to the last modification time
> until NTP synchronization is restored?

Delay startup of your application until you are sure that chrony is up and
running. For example, restart it only a minute after the bootup or a minute
after the network has come up again.  That should
be enough time for the makestep to work.


> Any help is appreciated, thanks in advance!
>
> Kind regards,
>
> Kris van Rens
>
> --
> 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.

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