| Message ID | 20241112192214.1644312-1-gael.portay+rtone@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] systemd: set better sane time at startup | expand |
I'm sorry, this was probably already covered and I'm just forgetful, but why not do this in do_install? Alex On Tue, 12 Nov 2024 at 20:22, Gaël PORTAY <gael.portay+rtone@gmail.com> wrote: > > When systemd is started, it sets the system clock to epoch to ensure the > system clock is reasonably initialized if no working RTC. > > As init process, systemd sets epoch very early to the more recent > timestamp of[1]: > - the build time of systemd (-Dtime-epoch) > - the modification time ("mtime") of /var/lib/systemd/timesync/clock > (systemd-timesyncd) > - the modification time ("mtime") of /usr/lib/clock-epoch (systemd) > > The first epoch timestamp is hard-coded at build-time by the systemd > recipe (using either SOURCE_DATE_EPOCH, git-tag, or NEWS modification > time[2]). > > The second epoch timestamp is maintained at run-time if the system runs > systemd-timesyncd. > > This implements the third epoch timestamp at image build-time, by > touching the timestamp file /usr/lib/clock-epoch from the package > post-install script. > > [1]: https://github.com/systemd/systemd/commit/863098fdc9cd91e4f760085356ac02c4b7ba6df1 > [2]: https://github.com/systemd/systemd/blob/v256/meson.build#L804-L825 > > Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com> > --- > Hello, > > With this patch, one can have a better sane default time set by systemd > very very very early in the boot (i.e. even before systemd outputs its > version!). > > # dmesg > (...) > [ 3.347641] Run /sbin/init as init process > [ 3.350435] with arguments: > [ 3.350440] /sbin/init > [ 3.350443] with environment: > [ 3.350447] HOME=/ > [ 3.350451] TERM=linux > [ 3.431275] EXT4-fs (mmcblk2p2): re-mounted. Opts: (null) > [ 3.523997] EXT4-fs (mmcblk2p4): recovery complete > [ 3.527828] EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: (null) > [ 3.694440] systemd[1]: System time before build time, advancing clock. > [ 3.714755] systemd[1]: systemd 250.5+ running in system mode (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK -SECCOMP -GCRYPT -GNUTLS +OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 -LZ4 -XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=hybrid) > > Thus, one can do time-based related things offline or before the system > clock is set by the network (if trusting the time does not matter that > much for sure). > > This happens if the system has no hardware clock or if it is way too far > in the past and if using an old versions of systemd; systemd v250.5 sets > the system time to April 28, 2022 5:53:22 PM (1651168402). > > Also, please set REPRODUCIBLE_TIMESTAMP_ROOTFS to any appropriate value > if enabling reproducible-builds (the default). Otherwise, bitbake sets > the timestamp to Friday, March 9, 2018 12:34:56 PM (1520598896, i.e. > REPRODUCIBLE_TIMESTAMP_ROOTFS[1]). > > **Important**: It works on scarthgap and kirkstone; "all" image files > are timestamped to Tuesday, April 5, 2011 11:00:00 PM (1302044400, i.e. > SOURCE_DATE_EPOCH_FALLBACK[2]) on master branch; that branch appears to > not use REPRODUCIBLE_TIMESTAMP_ROOTFS anymore. Therefore, an update of > the SOURCE_DATE_EPOCH_FALLBACK value should work (I guess). > > root@qemux86-64:~# stat /usr/lib/clock-epoch /etc/timestamp > File: /usr/lib/clock-epoch > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: fd00h/64768d Inode: 837 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2011-04-05 23:00:00.000000000 +0000 > Modify: 2011-04-05 23:00:00.000000000 +0000 > Change: 2011-04-05 23:00:00.000000000 +0000 > File: /etc/timestamp > Size: 15 Blocks: 2 IO Block: 1024 regular file > Device: fd00h/64768d Inode: 510 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2011-04-05 23:00:00.000000000 +0000 > Modify: 2011-04-05 23:00:00.000000000 +0000 > Change: 2011-04-05 23:00:00.000000000 +0000 > > SOURCE_DATE_EPOCH_FALLBACK ??= "1302044400" > > Supports Unix timestamps in seconds, milliseconds, microseconds and nanoseconds. > Assuming that this timestamp is in seconds: > GMT: Tuesday, April 5, 2011 11:00:00 PM > Your time zone: Wednesday, April 6, 2011 1:00:00 AM GMT+02:00 DST > Relative: 14 years ago > > [1]: https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n689 > [2]: https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n688 > > Changes since v1: > - use pkg_postinst() to touch file /usr/lib/clock-epoch instead of the > rootfs post-command rootfs_systemd_timestamp() > > Note: v1 is titled "classes: rootfs-postcommands: set better sane time > to systemd" > > https://patchwork.yoctoproject.org/project/oe-core/patch/20241019021935.2105739-1-gael.portay+rtone@gmail.com/ > > Kind Regards, > Gaël > meta/recipes-core/systemd/systemd_256.6.bb | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/meta/recipes-core/systemd/systemd_256.6.bb b/meta/recipes-core/systemd/systemd_256.6.bb > index 68f15ab065..f288bedc9e 100644 > --- a/meta/recipes-core/systemd/systemd_256.6.bb > +++ b/meta/recipes-core/systemd/systemd_256.6.bb > @@ -867,6 +867,10 @@ ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl" > ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel" > ALTERNATIVE_PRIORITY[runlevel] ?= "300" > > +pkg_postinst:${PN}:append () { > + touch $D${libdir}/clock-epoch > +} > + > pkg_postinst:${PN}:libc-glibc () { > if ${@bb.utils.contains('PACKAGECONFIG', 'myhostname', 'true', 'false', d)}; then > sed -e '/^hosts:/s/\s*\<myhostname\>//' \ > -- > 2.47.0 >
Alex, On Tue Nov 12, 2024 at 9:22 PM CET, Alexander Kanavin wrote: > I'm sorry, this was probably already covered and I'm just forgetful, > but why not do this in do_install? > It was initially performed by a rootfs post-command to mimic what does rootfs_update_timestamp() but for systemd. And you argued it is recipe specific and should not be a rootfs post-command. The idea was to create the file at image creation time in order to set a better date than the one hardcoded in the systemd binary (taken from the date of the tag IIRC). Also, playing with the variable $REPRODUCIBLE_TIMESTAMP_ROOTFS for the reproducible-builds (kirkstone, scarthgap). Note: Obviously, it is now the variable $SOURCE_DATE_EPOCH_FALLBACK to play with on the master branch. Peter suggested to move it to pkg_postinst:${PN} so the file is created at image creation time. > Alex > Regards, Gaël
On Wed, 13 Nov 2024 at 16:48, "Gaël PORTAY via lists.openembedded.org <gael.portay=gmail.com@lists.openembedded.org> wrote: > > Alex, > > On Tue Nov 12, 2024 at 9:22 PM CET, Alexander Kanavin wrote: > > I'm sorry, this was probably already covered and I'm just forgetful, > > but why not do this in do_install? > > > > It was initially performed by a rootfs post-command to mimic what does > rootfs_update_timestamp() but for systemd. And you argued it is recipe > specific and should not be a rootfs post-command. > > The idea was to create the file at image creation time in order to set a > better date than the one hardcoded in the systemd binary (taken from the > date of the tag IIRC). > > Also, playing with the variable $REPRODUCIBLE_TIMESTAMP_ROOTFS for the > reproducible-builds (kirkstone, scarthgap). > > Note: Obviously, it is now the variable $SOURCE_DATE_EPOCH_FALLBACK to > play with on the master branch. > > Peter suggested to move it to pkg_postinst:${PN} so the file is created > at image creation time. This is partly on me, for not paying enough attention to the mailing list, but our use case for the set-time-epoch PACKAGECONFIG (and time-epoch before it) is because we have a requirement that the system *always* boot with the time set to the epoch. This change breaks that case, but otherwise this seems like a reasonable change. How do people feel about wrapping the pkg_postinst append in this patch inside a PACKAGECONFIG check? Something like pkg_postinst:${PN}:append () { if ${@bb.utils.contains('PACKAGECONFIG', 'set-time-epoch', 'true', 'false', d)}; then touch $D${libdir}/clock-epoch fi } > > > Alex > > > > Regards, > Gaël > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#207136): https://lists.openembedded.org/g/openembedded-core/message/207136 > Mute This Topic: https://lists.openembedded.org/mt/109541328/3617261 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [danismostlikely@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
diff --git a/meta/recipes-core/systemd/systemd_256.6.bb b/meta/recipes-core/systemd/systemd_256.6.bb index 68f15ab065..f288bedc9e 100644 --- a/meta/recipes-core/systemd/systemd_256.6.bb +++ b/meta/recipes-core/systemd/systemd_256.6.bb @@ -867,6 +867,10 @@ ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl" ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel" ALTERNATIVE_PRIORITY[runlevel] ?= "300" +pkg_postinst:${PN}:append () { + touch $D${libdir}/clock-epoch +} + pkg_postinst:${PN}:libc-glibc () { if ${@bb.utils.contains('PACKAGECONFIG', 'myhostname', 'true', 'false', d)}; then sed -e '/^hosts:/s/\s*\<myhostname\>//' \
When systemd is started, it sets the system clock to epoch to ensure the system clock is reasonably initialized if no working RTC. As init process, systemd sets epoch very early to the more recent timestamp of[1]: - the build time of systemd (-Dtime-epoch) - the modification time ("mtime") of /var/lib/systemd/timesync/clock (systemd-timesyncd) - the modification time ("mtime") of /usr/lib/clock-epoch (systemd) The first epoch timestamp is hard-coded at build-time by the systemd recipe (using either SOURCE_DATE_EPOCH, git-tag, or NEWS modification time[2]). The second epoch timestamp is maintained at run-time if the system runs systemd-timesyncd. This implements the third epoch timestamp at image build-time, by touching the timestamp file /usr/lib/clock-epoch from the package post-install script. [1]: https://github.com/systemd/systemd/commit/863098fdc9cd91e4f760085356ac02c4b7ba6df1 [2]: https://github.com/systemd/systemd/blob/v256/meson.build#L804-L825 Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com> --- Hello, With this patch, one can have a better sane default time set by systemd very very very early in the boot (i.e. even before systemd outputs its version!). # dmesg (...) [ 3.347641] Run /sbin/init as init process [ 3.350435] with arguments: [ 3.350440] /sbin/init [ 3.350443] with environment: [ 3.350447] HOME=/ [ 3.350451] TERM=linux [ 3.431275] EXT4-fs (mmcblk2p2): re-mounted. Opts: (null) [ 3.523997] EXT4-fs (mmcblk2p4): recovery complete [ 3.527828] EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: (null) [ 3.694440] systemd[1]: System time before build time, advancing clock. [ 3.714755] systemd[1]: systemd 250.5+ running in system mode (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK -SECCOMP -GCRYPT -GNUTLS +OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 -LZ4 -XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=hybrid) Thus, one can do time-based related things offline or before the system clock is set by the network (if trusting the time does not matter that much for sure). This happens if the system has no hardware clock or if it is way too far in the past and if using an old versions of systemd; systemd v250.5 sets the system time to April 28, 2022 5:53:22 PM (1651168402). Also, please set REPRODUCIBLE_TIMESTAMP_ROOTFS to any appropriate value if enabling reproducible-builds (the default). Otherwise, bitbake sets the timestamp to Friday, March 9, 2018 12:34:56 PM (1520598896, i.e. REPRODUCIBLE_TIMESTAMP_ROOTFS[1]). **Important**: It works on scarthgap and kirkstone; "all" image files are timestamped to Tuesday, April 5, 2011 11:00:00 PM (1302044400, i.e. SOURCE_DATE_EPOCH_FALLBACK[2]) on master branch; that branch appears to not use REPRODUCIBLE_TIMESTAMP_ROOTFS anymore. Therefore, an update of the SOURCE_DATE_EPOCH_FALLBACK value should work (I guess). root@qemux86-64:~# stat /usr/lib/clock-epoch /etc/timestamp File: /usr/lib/clock-epoch Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: fd00h/64768d Inode: 837 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2011-04-05 23:00:00.000000000 +0000 Modify: 2011-04-05 23:00:00.000000000 +0000 Change: 2011-04-05 23:00:00.000000000 +0000 File: /etc/timestamp Size: 15 Blocks: 2 IO Block: 1024 regular file Device: fd00h/64768d Inode: 510 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2011-04-05 23:00:00.000000000 +0000 Modify: 2011-04-05 23:00:00.000000000 +0000 Change: 2011-04-05 23:00:00.000000000 +0000 SOURCE_DATE_EPOCH_FALLBACK ??= "1302044400" Supports Unix timestamps in seconds, milliseconds, microseconds and nanoseconds. Assuming that this timestamp is in seconds: GMT: Tuesday, April 5, 2011 11:00:00 PM Your time zone: Wednesday, April 6, 2011 1:00:00 AM GMT+02:00 DST Relative: 14 years ago [1]: https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n689 [2]: https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n688 Changes since v1: - use pkg_postinst() to touch file /usr/lib/clock-epoch instead of the rootfs post-command rootfs_systemd_timestamp() Note: v1 is titled "classes: rootfs-postcommands: set better sane time to systemd" https://patchwork.yoctoproject.org/project/oe-core/patch/20241019021935.2105739-1-gael.portay+rtone@gmail.com/ Kind Regards, Gaël meta/recipes-core/systemd/systemd_256.6.bb | 4 ++++ 1 file changed, 4 insertions(+)