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

Reply via email to