[systemd-devel] Masking mount units

[Lennart Poettering]

On Di, 29.10.24 08:28, Phillip Susi (phill at thesusis.net) wrote:

> Lennart Poettering <lennart at poettering.net> writes:
>
> > It prevents it fully. However, udev installs an inotify watch on all
> > relevant block devices, which watches for IN_CLOSE_WRITE events, and
> > then triggers the device again. IN_CLOSE_WRITE is the event that is
> > generated when an inode is closed after it was open for writing. For
> > block devices this means that when tools such as fdisk open the device
> > for writing and then close it, the devices will be fully automatically
> > reprobed afterwards (unless a BSD file lock is still in place then, by
> > somebody else).
> >
> > IN_CLOSE_WRITE is strictly speaking not the event we *actually* want
> > to watch for retriggering the device (that would be an event triggered
> > by the release of the file lock, but linux does not support generating
> > a lock then), but it's really close, because "close-after-write" and
> > "release lock" typically coincide, or are even the very same
> > operation.
>
> So if you want to prevent automounting entirely you have to... open the
> disk device read only and take the bsd lock, and hold it until after
> closing the write file descriptor?  Plus probably a little more time to
> give udev a chance to try and fail to take the lock?

Why keep it longer? The bsd file lock is effectively an rwmutex. As
long as your app has the lock, udev won't check it.

Ideally you take the lock on the fd you also use for writing. I am not
sure why you'd involve two fds?

Doing the locking on the fd you use for writing makes things a lot
easier, because as mentioned udev will automatically retrigger block
devices if an inotify event on it is seen that indicates
"close-after-write". If you deal with multiple fds you need to make
sure to close the fd used for writing *after* having released the
lock on the other one, because if you do it the other way round, udev
will retigger the device, but then not be able to lock device and not
actually do anything, and then no further inotify is seen and things
will remain out ofdate.

> Then again, this will also prevent the udevdb from being updated.  Maybe
> that is a bigger hammer than you really want when the goal is just to
> stop auto mounting?

If you change the superblock or part table of your disk, udev
shouldn't read half-written data, so yes, it's *good* it doesn't
update its udevdb. That's the whole point of the exercise!

I am not sure I grok what the problem is supposed to be here...

parted should just open the main block device for writing, take an
exclusive BSD lock on it, then do its thing, and close the fd. It's
very easy, and will bock generation of udev's uevents on the thing,
will block udev from reading half-written data and everything else.

Lennart

--
Lennart Poettering, Berlin