[systemd-devel] _netdev for system root mount?

[Andrei Borzenkov]

13.03.2020 11:19, Mantas Mikulėnas пишет:
> On Fri, Mar 13, 2020 at 10:03 AM Thomas Blume <Thomas.Blume at suse.com> wrote:
> 
>> Hi,
>>
>> I have a SUSE SLES system where system root is provided via iscsi firmware
>> (ibft).
>> The installer automatically adds the _netdev parameter to the system root
>> mount.
>> The ordering when applying the _netdev parameter is documented as:
>>
>> -->
>> Network mount units are ordered between remote-fs-pre.target and
>> remote-fs.target, instead of local-fs-pre.target and local-fs.target. They
>> also
>> pull in network-online.target and are ordered after it and network.target.
>> --<
>>
>> On system start, I can see this:
>>
>> -->
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device:
>> Dependency Before=network-online.target ignored (.device units cannot be
>> del>
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device:
>> Dependency Before=network.target ignored (.device units cannot be delayed)
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency
>> Before=network-online.target ignored (.device units cannot be delayed)
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network.target
>> ignored (.device units cannot be delayed)
>> --<
>>
>> Which looks like _netdev becomes almost a noop.
>> The only effect I can see afterwards is that the system root mount gets
>> ordered
>> below remote-fs.target:
>>
>>
> Somehow the 'cannot be delayed' message does not make sense with Before=.
> 
> But it feels like the dependency itself is backwards, too, it should be
> *After=* network.target... At least I see the regular
> systemd-fstab-generator adds After=, which makes more sense, but it still
> triggers the same message.
> 

This is just confusing message, current systemd should print
After=network.target here (see commit
c80a9a33d04fb4381327a69ce929c94a9f1d0e6c).

> I guess there's a bug in there somewhere but I'm not sure where.
> 
> 
>>
>> ● └─remote-fs.target
>> ●   ├─-.mount
>> ●   ├─boot-efi.mount
>> ●   └─iscsi.service
>>
>> But this is also a noop, because system root is already mounted in the
>> initrd
>> and has no more relevance after switch root.
>> It could be even dangerous, because on shutdown the system root mount
>> might be
>> attempted to stop before the system is switching back to the initrd.
>>
> 
> AFAIK the root mount is never stopped (and has the 'perpetual' flag set). I
> don't think it would even be *possible* to do so because pid1 itself is
> being executed from there, as well as there's still other filesystems
> (/run, /dev) mounted on top of it. (Which is the entire point of switching
> back to the shutdown-initramfs.)
> 
> Either way – stopping a mount literally just unmounts the filesystem (which
> is supposed to be a safe operation). I'd probably be more worried about
> iscsi.service, since the blockdev losing connection *before* its fs is
> unmounted is actually the dangerous part...
> 

And what is the "official" way to prevent various units required by root
mount from being stopped during shutdown? There could be arbitrarily
deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...).

And no, DefaultDepedencies=no is not an answer because it just shifts
the question to "how to add this directive to one instance only".