Hi Lennart,
thanks for answering.
If the mount really does not matter, is expected to take long or fail,
wouldn't "noauto" be the better choice, and in case "x-systemd.automount"?
The problem is, if we add "nofail" to a network mount, and it fails, it
causes the shutdown issue for all other network mounts, since
remote-fs.target fails, and hence looses its ability to order unmounts
on shutdown: https://github.com/systemd/systemd/issues/17221
And a failing local-fs.target can prevent login prompts to appear at all.
Of course we could (and mostly do) use automounts, where "nofail" is not
needed, because they are not part of the initial boot schedule, but are
ordered properly on shutdown, if automount kicked in. But automounts
have the dedicated issue that they hang the system for 90 seconds
(default timeout) if the network share server or network is down,
respectively a local drive is not available. When any automount point is
accessed during boot, it further hangs the system forever, which I did
not understand yet (why not only for 90 seconds). I wanted to create a
dedicated threat or issue about this, but here it just matters that
there are cases where x-systemd.automount is not suitable for other reasons.
Basically, what I am missing, is a way to have mounts attempted at boot,
properly ordered into boot schedule, without affecting the following
boot (and shutdown) schedule in any way on failure, but have them
properly ordered into shutdown cycled when their mount succeeded, or if
they were manually mounted later.
Best regards,
Micha
