[systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

Lennart Poettering lennart at poettering.net
Mon Jun 29 14:24:17 PDT 2015


On Mon, 29.06.15 20:36, jon (jon at jonshouse.co.uk) wrote:

> What for example is the technical reason why the "nofail" logic could
> not have been inverted ? I have not heard any technical argument that is
> compelling as to why this could not have worked the other way up and
> default behaviour not have been kept, other than that would require to
> cooperation from the installer authors to add "some other flag" to
> volumes that must always be available at boot time?

Well, there are two kinds of mounts: some where it is essential that
they are around when the system boots up, and others where it isn't.

A mount on /var is clearly essential, as area pretty much all mounts
below /var, though there might be exceptions. Mounts in /srv are
essential, too. Mounts which are often non-essential are external
media, USB sticks and suchlike. However, those are probably usually
handled via something like udisks, and only in exceptions via
/etc/fstab. That together is already indication that the current
behaviour should be the default when you don't specify something
anything.

Three other reasons are: "nofail" already exists in util-linux for a
long time, and there is not "fail" option defined, hence for systemd
too the "nofail" case is the opt-in and "fail" is the default. And the
other is: changing behaviour forth and back and forth and back is
just wrong. The behaviour systemd exposes has been this way for 5y
now, and we shouldn't change it without a really string reason -- but
I am pretty sure your specific usecase does not qualify.

Also, again, "nofail" predates systemd: you should have used it for
your usecase even in sysvinit. If you so will, then the old setup was
already borked for you, even though admittedly the effect was less
fatal.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list