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

[Franck Bui]

On 01/24/2018 04:33 PM, Lennart Poettering wrote:
>> 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).

It's not about udev here but it's about systemd which does a high-level
operation on the back of partition management tools (in fact some of
those tools may rely on udev's notifications)

We could suggest another workaround by masking the mount units before
operating on the block device. But it's still a workaround IMHO.

Indeed I can't see any useful use cases for this functionality
implemented by systemd and I'm really not sure there are users out there
who find it useful.

So why was it introduced in the first place ?

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

Again I don't see why PID1 would need to implement such feature.
> 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...
>

I disagree here.

Initially "noauto" is interpreted only (?) by "mount -a" which was done
during boot and can still be re-played later by admin. But in the later
case the command is *initiated* by him so there's no magic here.

systemd redefined this though: "auto" is equivalent to "run 'mount -a'
automatically when a backend device appears on udev's radar" which is
totally different. And it's the default: if neither "noauto" nor "auto"
is specified then the redefined "auto" is assumed.

The proposed change keeps the old default behavior: if neither "auto"
nor "noauto" is specified, do the equivalent of "mount -a" during boot only.

If "auto" is explicitly specified then keep the behavior introduced by
systemd too minimize the incompatible changes.

But honestly I would be in favor to remove it completely, see below.

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

And we get regularly complains about this behavior.

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

We're taking about filesystems listed in fstab.

In my understanding fstab is not the placed to declare filesystems that
should be automagically mounted by apps. It should be mostly used by
"mount -a" during the boot process or when the command is issued by admins.

Actually I would tend to think that apps should leave alone any
filesystems in fstab, which usually lists filesystems used to setup the
system.

And systemd offers already another and better way to automatically
mounts filesystem when their target directory is accessed with automount
units.

So my best option would be to remove completely the redefinition of
"auto" option we have currently and would make it behaves like it did in
the past. If this "automagic" behavior appears to have some useful cases
then implement it via a totally different option supported by mount unit
(only) so there's no confusion anymore.

Thanks.