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

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Andrei Borzenkov <arvidjaar@xxxxxxxxx> schrieb am 14.12.2019 um 09:58 in
Nachricht <815efe10-890b-e942-b091-9c16de2b9444@xxxxxxxxx>:
> 09.12.2019 10:06, Ulrich Windl пишет:
>>>
>>> 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?
> 
> It has nothing to do with being "newer". It allows managing initrd
> filesystems in one place and avoids need to re-create initrd every time
> you need additional filesystem.
> 
>> 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.
>> 
> 
> It fits perfectly into systemd design goal - start services *on boot*
> once. Most problems with systemd stem from attempt to use it as "dynamic
> service manager" which it is not. This discussion is example of it.

Then why does systemd unmount filesystems that I manually mount? Or mount
filesystems that I manually unmount? If it were doing thing just "once" that
wouldn't happen repeatedly.

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel