* RFC: Should sync-clock.services use --utc
@ 2024-04-10 21:59 Jon Cormier
2024-04-11 1:09 ` [meta-arago] " Randolph Sapp
[not found] ` <17C514807157F9C8.4467@lists.yoctoproject.org>
0 siblings, 2 replies; 6+ messages in thread
From: Jon Cormier @ 2024-04-10 21:59 UTC (permalink / raw)
To: meta-arago, Denys Dmytriyenko; +Cc: Andrew Meek
[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]
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.
--
Jonathan Cormier
Software Engineer
[-- Attachment #2: Type: text/html, Size: 2917 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-arago] RFC: Should sync-clock.services use --utc
2024-04-10 21:59 RFC: Should sync-clock.services use --utc Jon Cormier
@ 2024-04-11 1:09 ` Randolph Sapp
2024-04-11 15:48 ` Jon Cormier
[not found] ` <17C514807157F9C8.4467@lists.yoctoproject.org>
1 sibling, 1 reply; 6+ messages in thread
From: Randolph Sapp @ 2024-04-11 1:09 UTC (permalink / raw)
To: jcormier, meta-arago, Denys Dmytriyenko, reatmon, afd; +Cc: Andrew Meek
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-arago] RFC: Should sync-clock.services use --utc
2024-04-11 1:09 ` [meta-arago] " Randolph Sapp
@ 2024-04-11 15:48 ` Jon Cormier
2024-04-11 16:50 ` Randolph Sapp
0 siblings, 1 reply; 6+ messages in thread
From: Jon Cormier @ 2024-04-11 15:48 UTC (permalink / raw)
To: Randolph Sapp; +Cc: meta-arago, Denys Dmytriyenko, reatmon, afd, Andrew Meek
[-- Attachment #1: Type: text/plain, Size: 4824 bytes --]
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 <rs@ti.com> 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
>
--
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>
[-- Attachment #2: Type: text/html, Size: 7299 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-arago] RFC: Should sync-clock.services use --utc
[not found] ` <17C514807157F9C8.4467@lists.yoctoproject.org>
@ 2024-04-11 16:43 ` Randolph Sapp
0 siblings, 0 replies; 6+ messages in thread
From: Randolph Sapp @ 2024-04-11 16:43 UTC (permalink / raw)
To: rs, jcormier, meta-arago, Denys Dmytriyenko, reatmon, afd; +Cc: Andrew Meek
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-arago] RFC: Should sync-clock.services use --utc
2024-04-11 15:48 ` Jon Cormier
@ 2024-04-11 16:50 ` Randolph Sapp
2024-04-11 17:24 ` Jon Cormier
0 siblings, 1 reply; 6+ messages in thread
From: Randolph Sapp @ 2024-04-11 16:50 UTC (permalink / raw)
To: Jon Cormier; +Cc: meta-arago, Denys Dmytriyenko, reatmon, afd, Andrew Meek
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 <rs@ti.com
> <mailto:rs@ti.com>> 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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-arago] RFC: Should sync-clock.services use --utc
2024-04-11 16:50 ` Randolph Sapp
@ 2024-04-11 17:24 ` Jon Cormier
0 siblings, 0 replies; 6+ messages in thread
From: Jon Cormier @ 2024-04-11 17:24 UTC (permalink / raw)
To: Randolph Sapp; +Cc: meta-arago, Denys Dmytriyenko, reatmon, afd, Andrew Meek
[-- Attachment #1: Type: text/plain, Size: 6735 bytes --]
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 <rs@ti.com> 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 <rs@ti.com
> > <mailto:rs@ti.com>> 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>
[-- Attachment #2: Type: text/html, Size: 10983 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-11 17:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-10 21:59 RFC: Should sync-clock.services use --utc Jon Cormier
2024-04-11 1:09 ` [meta-arago] " Randolph Sapp
2024-04-11 15:48 ` Jon Cormier
2024-04-11 16:50 ` Randolph Sapp
2024-04-11 17:24 ` Jon Cormier
[not found] ` <17C514807157F9C8.4467@lists.yoctoproject.org>
2024-04-11 16:43 ` Randolph Sapp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).