[systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

[Lennart Poettering]

On Di, 23.01.18 15:47, Franck Bui (fbui at suse.de) wrote:

> Hi,
> 
> I'm resurrecting an old but recurrent issue here which I'd like to
> clarify one more time.
> 
> Basically, systemd mounts all filesystems listed in /etc/fstab (unless
> "noauto" is used) which is good since that's how fstab was used when
> SysV was the init system.
> 
> However it also introduced another "feature" which basically
> automagically mounts a filesystem (listed in fstab) every time its
> backend device re-appears.
> 
> And this part confuses a lot of users since fstab has always been used
> to list filesystems that should be mounted during the boot process
> only. It has never been the place used by disk managers to list
> mount-points that should be automatically mounted after the system
> booted.

Well, the way I understood "auto" as opposed to "noauto" was "make
sure this is mounted while the system is up"...

I think it's moot discussing which intrepretation is the more correct
there, though…

> Furthermore, it complicates the disk administrative tasks because now
> one needs to be careful when it creates and initialize partitions
> because systemd can mount the partition on the back of the user. We
> recently had one such bug report (again).

You have to be careful there anyway. If you want exclusive access to a
block device, and don't want udev (and thus ultimately systemd) take
notice while you do that then take a BSD file lock on the device (see
other mail). Note that systemd is just one consumer of udev's
notifications there, and if you want to block all of them out while
you manipulate your block device, then there's no way around taking
the BSD lock anyway...

> According to Lennart[1], this feature is there because:
> 
>   "mount it if it is around at boot, but not later" is not
>   available, since the idea is not compatible with modern
>   storage.
> 
> I'm not sure why the old behavior is not compatible with modern
> storage but with the following trivial change:
> 
>    static bool mount_is_auto(const MountParameters *p) {
>            assert(p);
> 
>   -        return !fstab_test_option(p->options, "noauto\0");
>   +        return fstab_test_option(p->options, "auto\0");
>    }
> 
> it seems to me that it could have the best of both worlds.

Well, traditionally "auto" was a boolean (and it is in the /bin/mount
sources still): "auto" means on, "noauto" means off. And the default
was "auto". Redefining this to make something else the default, or
even treating this as a tri-state now of "on", "off",
"something-in-between" sounds like a bigger redefinition than the
change systemd made there...

> So the question is now: "what am I missing ?"

I am not convinced the reasoning is convincing for such a major change
(I mean, let's not forget that systemd's current behaviour has been
around for more than half a decade too already). If you want other
bits of the code not to interfere what you are doing, then take the
BSD lock and all will be good, it's the right, the better thing to do,
and you have to do it anway. It will not only stop systemd from
interfering but everything else too...

Lennart

-- 
Lennart Poettering, Red Hat