[systemd-devel] Antw: Re: Why does initrd-parse-etc.service re-start initrd-fs.target?

[Ulrich Windl]

>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 06.12.2019 um 18:53 in
Nachricht <3cbf0f7e-f6ae-d8f5-dbcf-aa830c1495b7 at gmail.com>:
> 05.12.2019 17:31, Colin Walters пишет:
>> See https://github.com/coreos/ignition-dracut/pull/140 
>> 
>> Basically, we do a lot of nontrivial stuff in the initramfs (Ignition) and

> this was re-starting some of our units, which I found surprising.
>> 
>> The behavior seems to have come from 
>
https://github.com/systemd/systemd/commit/7d89ce303fb59743a4392eeb3110c00f100

> 172ca
> 
> It was there much earlier, just that it restarted local-fs.target then.
> 
>> 
>> Now, I understand the goal of having systemd re-load its configuration, but

> why do we need to start the initrd-fs.target unit again?  Can't we assume 
> that the mount points set up for the root are still active?
> 
> After real root is mounted daemon-reload re-runs fstab generator which
> parses real root /etc/fstab and may pull mount points from it.

I wonder: Are there realistic cases when the fstab in initrd is newer than the
fstab in the root file system? That would be the case where detecting a "new"
fstab would fail. I didn't dig into the generators, but an alternative method
to detect a file change would be to compare the size as well (as cheap as
stat()), or to compare some checksum (requires some more extra code). I feel
the generators should fix the issue, not the user (i.e. restart).

> Restarting initrd-fs.target will propagate start request to its (newly
> created) dependent mount units. Otherwise there is no obvious way to
> start them (without explicitly starting each).

I never liked the idea of generators and /etc/fstab.

> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel