On Mi, 24.01.18 22:12, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 24.01.2018 22:08, Lennart Poettering пишет: > > On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > 1;5002;0c > >> 24.01.2018 17:13, Lennart Poettering пишет: > >>> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel