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

[Thomas Blume]

On Tue, 23 Jan 2018, Simon McVittie wrote:

>> 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.


Suppressing the auto mount when a device (re)appears, is usually desired
during some administrative tasks.
What about lowering the hurdle for administrators by introducing a new
systemctl command?

Maybe something like:

systemctl lock $DEVICE

We could write the name of $DEVICE in some directory below /run/systemd.
An udev rule could parse this directory when an add event for a device
occurres and if $DEVICE matches, it could set SYSTEMD_READY=0.
We would only need to make sure that SYSTEMD_READY gets reset back to 1 at an:

systemctl unlock $DEVICE

That shouldn't be too hard to code either.

Would this be an acceptable approach?

Regards
Thomas