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

    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>



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