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

[Colin Guthrie]

Franck Bui wrote on 25/01/18 08:11:
>> 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.

Isn't the whole "mount -a during boot" a fundamentally fuzzy concept? I
mean, "in the past" this only worked because there were artificial
delays introduced to make sure all devices were probably available
before trying to mount them.

As systemd is more reactive (i.e. hotplug friendly) what's to say a
device plugged in 2s after boot is not a device plugging in at boot but
which takes a while to appear on the bus and filter through to become a
device node?

I don't think it would make technical sense to define a period in time
which flips systemd over to behaving differently. That would be very
confusing and hard to define and convey to users. At least the current
way is consistent even if it does have some other issues to contend with.

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/