On Thu, Oct 22, 2020 at 10:52 AM Lennart Poettering <mzxre...@0pointer.de> wrote: > > On Mi, 21.10.20 22:13, Belisko Marek (marek.beli...@gmail.com) wrote: > > > Hi, > > > > I'm facing a strange issue. When I boot system using systemd (244.3) > > and in one service I'm generating some certificates. When checking > > them I'm getting the result that the certificate was created 1.1.1970 > > which is invalid. I can wait until I get a network connection and only > > then create certificates but I have only issues that some files are > > created and I'm getting date/time creation also epoch. Shouldn't it be > > the date/time of build? Can this be caused somehow by using read only > > rootfs? Thanks a lot for any pointers. > > This is strange. PID1 actually bumps the system clock to whatever > was chosen as "epoch" during build. By default that's the mtime of the > NEWS file in the source tree, i.e. usually the time of the used > systemd release. > > Thus, Jan 1970 should never be seen, unless your build explicitly > forces the epoch to be that. But why would you? Nope I'm not and it's not my intention. I checked systemd source code and I find out that systemd-update-done service add timestamp when /usr was created but in my case: * systemd-update-done.service - Update is Completed Loaded: loaded (/lib/systemd/system/systemd-update-done.service; static; vendor preset: disabled) Active: inactive (dead) Condition: start [[0;1;38;5;185mcondition failed[[0m at Thu 1970-01-01 00:21:30 UTC; 3min 49s ago |- ConditionNeedsUpdate=|/etc was not met `- ConditionNeedsUpdate=|/var was not met Docs: man:systemd-update-done.service(8)
Jan 01 00:05:08 hostname-modified-by-marek systemd[1]: Condition check resulted in Update is Completed being skipped. Jan 01 00:21:30 hostname-modified-by-marek systemd[1]: Condition check resulted in Update is Completed being skipped. and when ls -la /usr I'm getting: ls -la /usr/ total 64 drwxr-xr-x 11 root root 4096 Mar 9 2018 . drwxr-xr-x 20 root root 4096 Oct 16 2020 .. drwxr-xr-x 3 root root 16384 Mar 9 2018 bin drwxr-xr-x 2 root root 4096 Mar 9 2018 games drwxr-xr-x 3 root root 4096 Mar 9 2018 include drwxr-xr-x 21 root root 12288 Mar 9 2018 lib drwxr-xr-x 4 root root 4096 Mar 9 2018 libexec drwxr-xr-x 8 root root 4096 Mar 9 2018 runcfg drwxr-xr-x 2 root root 4096 Mar 9 2018 sbin drwxr-xr-x 28 root root 4096 Mar 9 2018 share drwxr-xr-x 2 root root 4096 Mar 9 2018 src so it also looks awkward because the build was created a few hours ago but OK. > > systemd-timesyncd also maintains a touch file that is updated whenever > an NTP sync is acquired and is used to bump the system clock at > boot. This uses a file in /var/. If you have an entirely immutable OS > image this cannot work of course... And because this needs /var/ > around this happens only after that is mounted, i.e. not during > earliest boot, but a bit later than that. > > Hence summary: we bump to compiled-in epoch super early, in PID 1, and > from a touch file once systemd-timesycnd initializes. > > You never should see 1970 as system clock though once PID 1 initialized > (unless you change the epoch during build manually), and you should > see monotonic time once systemd-timesyncd started. And correct time > should be available once systemd-timesyncd got an NTP fix, which you > is after systemd-time-wait-sync.service. > > Or in other words: > > 1. An early boot service (i.e. with DefaultDependencies=no) and no > special After= line should see system clock bumped to at least the > compiled-in epoch > > 2. Any service (early boot or regular) with > After=systemd-timesyncd.service line should see the system clock bumped > to at least the time of last shutdown — if /var is writable. > > 3. Any service (early boot or regular) with > After=systemd-time-wait-sync.service and > Wants=systemd-time-wait-sync.service should see the system clock > initialized correctly — if networking connectivity worked and an > NTP fix could be acquired of course. > > Lennart > > -- > Lennart Poettering, Berlin Thanks, marek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel