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

[Lennart Poettering]

On Mi, 24.01.18 22:12, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> 24.01.2018 22:08, Lennart Poettering пишет:
> > On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
> > 1;5002;0c
> >> 24.01.2018 17:13, Lennart Poettering пишет:
> >>> On Mi, 24.01.18 14:51, Thomas Blume (Thomas.Blume at suse.com) wrote:
> >>>
> >>>> Would this be an acceptable approach?
> >>>
> >>> Since a long time there has been a proper API for this: just take a
> >>> BSD file lock on the device node and udev won't bother with the
> >>> device anymore. As soon as you close the device fully (and thus also
> >>> lost all locks), udev will notice and then reprobe it again.
> >>>
> >>
> >> How exactly is udev relevant here? This discussion has nothing to do
> >> with udev.
> > 
> > systemd acts on udev's notifications. Other daemons do too. If you
> > don't want that all those apps and services act on it for your block
> > device, then the right approach is to block udev from doing so,
> > i.e. go to the source, not to the symptom.
> 
> You cannot lock device that does not exist. And as soon as it appears it
> is mounted.

hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there
to be a known path for a device, hence it must already be plugged in
already?

Also, it's not that systemd takes possession of arbitrary devices just
like that. It does that because the device was listed explicitly in
/etc/fstab as "auto" already, and your system wouldn't even have booted if
the device didn't show up during boot. 

I think you have a different usecase though? Not sure I grok it
though? you want to turn off all hotplug handling for all future
devices entirely? what's the usecase?

Lennart

-- 
Lennart Poettering, Red Hat