Hmm, the code your pointing to should be old enough to be included in the am57x busybox and systemd versions. However, the file doesn't exist and isn't being created when I run the hwclock command.
On Thu, Apr 11, 2024 at 12:50 PM Randolph Sapp <[email protected]> wrote: > Yeah, the first time `hwclock --systohc` is run on the system the > /etc/adjtime file should be created to track the hwclock drift and > configuration. You may have to run this manually. > > On 4/11/24 10:48, Jon Cormier wrote: > > Hmm, I was testing this on the AM57x and that filesystem doesn't have a > > /etc/adjtime file. Is this a new file? Or is there a recipe I am > missing? > > > > My understanding of your email is that with /etc/adjtime in place, then > > the sync-clocks script is no longer needed? > > > > If I disable it on my AM57x, the system time doesn't get set on boot > > unless NFS is available. > > > > On Wed, Apr 10, 2024 at 9:09 PM Randolph Sapp <[email protected] > > <mailto:[email protected]>> wrote: > > > > On Wed Apr 10, 2024 at 4:59 PM CDT, Jon Cormier via > > lists.yoctoproject.org <http://lists.yoctoproject.org> wrote: > > > I'd like to propose the following change, to resolve what appears > > to be a > > > difference between how timedatectl is reading the rtc and > > > sync-clocks.service is reading it. > > > > > > recipes-core/systemd/systemd/sync-clocks.service: > > > -ExecStart=/sbin/hwclock --systohc > > > +ExecStart=/sbin/hwclock --utc --systohc > > > > > > busybox hwclock by default assumes RTC is in local timezone but > > can be told > > > to treat rtc time as UTC by adding --utc. > > > timedatectl by default assumes the RTC time is in UTC, "RTC in > > local TZ: > > > no". > > > > > > Note testing needs to be done with network disconnected otherwise > > ntp takes > > > over. > > > > > > When system TZ is UTC, local, universal, and rtc time match. > > > > > > root@mitysom-am57x:~# timedatectl > > > Local time: Wed 2024-04-10 20:55:35 UTC > > > Universal time: Wed 2024-04-10 20:55:35 UTC > > > RTC time: Wed 2024-04-10 20:55:36 > > > Time zone: n/a (UTC, +0000) > > > System clock synchronized: yes > > > NTP service: active > > > RTC in local TZ: no > > > root@mitysom-am57x:~# hwclock -r > > > Wed Apr 10 20:55:368 2024 0.000000 seconds > > > > > > When system TZ is changed to EST, universal and rtc still match, > > this makes > > > sense. > > > > > > root@mitysom-am57x:~# timedatectl set-timezone America/New_York > > > root@mitysom-am57x:~# timedatectl > > > Local time: Wed 2024-04-10 17:12:06 EDT > > > Universal time: Wed 2024-04-10 21:12:06 UTC > > > RTC time: Wed 2024-04-10 21:12:01 > > > Time zone: America/New_York (EDT, -0400) > > > System clock synchronized: yes > > > NTP service: active > > > RTC in local TZ: no > > > root@mitysom-am57x:~# hwclock -r > > > Wed Apr 10 21:12:02 2024 0.000000 seconds > > > > > > However, after a reboot, RTC time now matches the Local time > > instead. If > > > you plug in networking and NTP takes over, RTC time will jump > > back to UTC. > > > > > > root@mitysom-am57x:~# timedatectl > > > Local time: Wed 2024-04-10 17:13:33 EDT > > > Universal time: Wed 2024-04-10 21:13:33 UTC > > > RTC time: Wed 2024-04-10 17:13:33 > > > Time zone: America/New_York (EDT, -0400) > > > System clock synchronized: no > > > NTP service: active > > > RTC in local TZ: no > > > root@mitysom-am57x:~# hwclock -r > > > Wed Apr 10 17:13:35 2024 0.000000 seconds > > > > > > With the above-proposed change, this RTC time changing to local > > time no > > > longer happens. > > > > Thanks for bringing this up. I was curious why the system time kept > > jumping > > around but I never thought we would have done something like this... > > > > The system time is set with the hwclock and the contents of > > /etc/adjtime, which > > is created by the first `hwclock --systohc` run on the system. Both > > systemd and > > busybox respect that, assuming they haven't been configured > > specifically to > > ignore that [1] [2] [3]. > > > > So the addition of the UTC flag should be unnecessary. The two > > should read > > /etc/adjtime and adjust accordingly. > > > > [1] https://git.busybox.net/busybox/tree/util-linux/hwclock.c#n478 > > <https://git.busybox.net/busybox/tree/util-linux/hwclock.c#n478> > > [2] https://git.busybox.net/busybox/tree/libbb/rtc.c#n10 > > <https://git.busybox.net/busybox/tree/libbb/rtc.c#n10> > > [3] > > > https://github.com/systemd/systemd/blob/d0ea8009434935758c8e96038f052d7bbb0b7dfe/src/shared/clock-util.c#L54 > < > https://github.com/systemd/systemd/blob/d0ea8009434935758c8e96038f052d7bbb0b7dfe/src/shared/clock-util.c#L54 > > > > > > That being said, having a systemd service trigger systohc on every > > boot is not > > only redundant, but it ensures that the hwclock is always jumping > > past the last > > value, even if it was actually correct. It's almost certainly worse > > that having > > an old date and waiting for ntp to catch us up, as it cause system > > logs to jump > > backwards in time. I would like to propose we remove this service > > altogether. > > > > Also a fun bit of info: > > > Since systemd version 216, when the RTC is configured to the > > local time (rather > > > than UTC) systemd will never synchronize back to it > > > > - Randolph > > > > > > > > -- > > Jonathan Cormier > > Software Engineer > > > > Voice: 315.425.4045 x222 > > > > > > > > http://www.CriticalLink.com <http://www.criticallink.com/> > > 6712 Brooklawn Parkway, Syracuse, NY 13211 > > > > <https://www.linkedin.com/company/critical-link-llc> > > <https://twitter.com/Critical_Link> > > -- Jonathan Cormier Software Engineer Voice: 315.425.4045 x222 http://www.CriticalLink.com <http://www.criticallink.com/> 6712 Brooklawn Parkway, Syracuse, NY 13211 <https://www.linkedin.com/company/critical-link-llc> <https://twitter.com/Critical_Link> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15268): https://lists.yoctoproject.org/g/meta-arago/message/15268 Mute This Topic: https://lists.yoctoproject.org/mt/105451810/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-arago/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
