On Wed Apr 10, 2024 at 8:09 PM CDT, Randolph Sapp via lists.yoctoproject.org 
wrote:
> On Wed Apr 10, 2024 at 4:59 PM CDT, Jon Cormier via 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
> [2] https://git.busybox.net/busybox/tree/libbb/rtc.c#n10
> [3] 
> 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

Sorry, I'm going to blame sleep deprivation on this piece.

tldr: The sync-clocks service shouldn't be causing any issues. That being said,
it's redundant because of other time synchronization services now.

- Randolph


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15266): 
https://lists.yoctoproject.org/g/meta-arago/message/15266
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]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to