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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel