Comment # 38 on bug 902612 from Andrei Borzenkov

(In reply to Werner Fink from comment #35)
> (In reply to Per Jessen from comment #30)
> 
> AFAIK and AFAICS after a umount a device remains unmounted.  Only if you
> causing a kernel event (which umount/mount do not) accordingly with such a
> device the systemd will mount if the device is part of the /etc/fstab
> without noauto option set.

Even this does not happen consistently. Sometimes it will not mount; sometimes
it will.

> 
> (In reply to Andrei Borzenkov from comment #32)
> 
> What exactly, beside disabling a major feature[1], should the patch
> 
>   systemd-do-not-add-Wants-to-device-for-mount-and-swap.patch
> 
> do here?  Does this mean that we now have readd the `mount -a' and also a
> `swapon -a' within an own service unit? 
> 

No. You misunderstand how mounting on boot works. Did you actually try my
build? Was any filesystem missing?

> 
> [1] For all here in this bug: Please could we have a real solution which
> will be acceptable for upstream as well?  It is a matter of fact that
> mounting devices from /etc/fstab is event driven

It is not. Filesystems from /etc/fstab are added as Requires dependencies to
local-fs.target. On boot local-fs.target gets started which triggers start of
mount units for filesystems from /etc/fstab. Only on this stage is Wants added
to device. So it is exactly opposite - this stupid dependency is added
*because* filesystem gets pulled in by some other unit, not filesystem gets
mounted because this dependency exists.


(In reply to Thomas Blume from comment #36)
> 
> 2. make sure that systemd only automounts an fstab entry at the first device
> 

Yes. This was always the semantic of /etc/fstab and there is no reason to
change it incompatibly. For anyone wanting something different there are native
mount units - you are free to express any fancy dependency there. If you want
automount on device appearance - just add Wants to device unit. Explicitly.

The main problem of current situation is not that it does something stupid by
default - but that there is no way to disable this without losing major
functionality.

> The most user friendly one, is probably option 2, as it combines the event
> driven behaviour of systemd, and the oneshot behaviour of SystemV mount.
> Not really sure how to implement this, though. 
> 

My patch does it :) If you accept that it had never been event driven in the
first place ...

(In reply to Stanislav Brabec from comment #37)
> >
> >What problems are you trying to solve?
> Current fstab situation:
> 
> - All "auto" (the default) mounts are handled by systemd.
> - All "auto" (the default) mounts are handled by mount -a.
> 

Sorry? Where is "mount -a" in boot sequence? Could you elaborate what you mean?