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

[Franck Bui]

On 01/25/2018 06:33 PM, Uoti Urpala wrote:
> 
> This would require distinguishing "boot" and "non-boot" modes of
> operation, so that systemd could switch mount handling behavior at some
> point. How would you define where "boot" ends? 

Well "during boot" means mount units pulled in by local-fs.target unit.

Once pulled in by the initial transaction, a mount unit can either:

  1. succeed if the device is already there and mount(8) succeeds
  2. wait for the device appears or a timeout expire
  3. enter in failed state if the timeout expires

This is the defaults and would match the behavior of SysV when it .

The concern here is that PID1 added a new behavior on top of that:

  4. Each time the mount unit is inactive and the device shows up
     automatically start the unit.

And indeed, if the device takes 5 hours to start, this "new" behavior
allows PID1 to mount asynchronously the device regardless of what
happened previously (assuming "nofail" option is used). But at first
glance disabling the timeout seems more appropriate...

Also how apps/users are supposed to access such devices ? should they
wait for systemd to signal that the mount unit is up ? isn't automount
more appropriate in this case ?

Even if some users might find it useful, redefining the meaning of
"auto" option doesn't look correct because as already explained a lot of
users dont expect it and it confuses some applications too.

IMHO introducing it with a brand new option would have been better and
much less confusing. Also this option shouldn't have been specific to
fstab but should have been part of the mount unit option set.

Thanks.