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.r...@vinotion.nl> 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-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
