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

Hello,

Defer to others on chrony support itself.

In past systems I've worked on with similar constraints, we had our own custom process which would save the time to some non-volatile storage, about once a minute, or whatever is best for you (don't forget to consider flash wear and tear if using flash).

Then, during boot up, we restore the time using this previously saved value (especially if the RTC time is stale/old/grossly wrong). Of course, make sure you can validate it or checksum the file, or whatever is best in this system, in case it has never been saved in the past (i.e. fresh install, or other failure mode).

After that, start chrony per normal, etc.

Also, make sure to 'sync' after saving the time. Linux loves to cache stuff in RAM and sync to disk later... which is difficult if dealing with frequent power loss.

Good luck,

Matthew Eshleman

On Wed, Mar 9, 2022 at 8:37 AM Kris van Rens <kris.van.rens@xxxxxxxxxxx> wrote:

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

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,
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
to force resetting the time at boot to the last modification time
until NTP synchronization is restored?

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.