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

[Simon McVittie]

On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:
> 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.

Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?

If you don't want systemd to do its best to ensure that a particular
filesystem is always mounted, please add the noauto option to it. In the
absence of noauto, consumers of fstab (including udev and systemd) assume
that you want this filesystem mounted at all times (between early startup
and late shutdown), and will get as close to that as is achievable.

> [fstab] has never been the place used by disk managers to list
> mount-points that should be automatically mounted after the system
> booted

That's not true, some dynamic disk managers outside systemd (at least
udisks) do respect configuration in fstab.

> I'm not sure why the old behavior is not compatible with modern
> storage

The traditional behaviour requires you to have a well-defined point during
boot at which you know that all hardware that was attached at power-on has
been detected, and all hardware that subsequently appears was hot-plugged
and should go through a different code path; but with modern buses
(most visibly USB, but also buses that you probably think of as more
static than they really are), there is no time at which you can know
that all hardware that was attached at power-on has now been detected.

It would be possible to use an arbitrary timeout, but arbitrary timeouts
are a problematic design: either they're too short and they unpredictably
miss some initially-attached hardware, or they're too long and they
arbitrarily slow down everyone's boot process, or (more likely) both
failure modes at the same time for different people.

    smcv