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

[Lennart Poettering]

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?

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