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

[Zbigniew Jędrzejewski-Szmek]

On Sat, Dec 14, 2019 at 11:58:37AM +0300, Andrei Borzenkov wrote:
> 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.

I'd go even further: initramfses should not need to be rebuilt all the time.
I.e. they should be what dracut calls hostonly=no. Having to propagate configuration
files from the host to the initramfs is very costly.

So yeah, in general I think we need to think about mechanisms which pull
all possible information from the host. This is never going to be as simple
as encoding all configuration statically in the initramfs, but that's the
price we have to pay for usability.

Zbyszek

> > 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.