[systemd-devel] date/time set to epoch when using readonly rootfs

[Belisko Marek]

On Thu, Oct 22, 2020 at 10:52 AM Lennart Poettering
<mzxreary at 0pointer.de> wrote:
>
> On Mi, 21.10.20 22:13, Belisko Marek (marek.belisko at 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