[systemd-devel] Masking mount units

[Lennart Poettering]

On Do, 31.10.24 09:03, Phillip Susi (phill at thesusis.net) wrote:

> Lennart Poettering <lennart at poettering.net> writes:
>
> > 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
>
> That is exactly what I DON'T want to happen.  If udev retriggers when
> the fd is closed, then that results in the partition being automatically
> mounted just because libparted read the partition table.

Two things:

1. The inotify is installed for close-after-*write*. Just opening the
   device for *read* and closing it will thus *not* result in the
   device to be retriggered and any uevents to be sent out. So if
   libparted just "reads the partition table" this should not result
   in an event.

2. And of course, this is a *lock*. Keep the fd you are operating with
   open and locked *as* *long* *as* you don#t want udev to reprobe it,
   and issue uevents for it.

> > 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.
>
> That is what I WANT to happen.  Well, at least I don't want a partition
> to be automatically mounted.  It would be nice if udevdb could still
> be updated.

Why? Again, if parted is modifyig the partition table, changing
superblocks and whatnot, then udev should *not* read anything off the
disk while it is doing so, because it would read half-written info
potentially.

> >> 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...
>
> Right, you don't want it to read half updated data, but if I
> intentionally prevent udev from looking at the disk _at all_ ( so that
> partitions don't get auto mounted ), then it also means that it never
> looks at the finished updates either and updates udevdb.

I am not following anymore?

It's a lock! Open the device, lock it, make your changes, once you are
done close (and thus implicitly release lock). That's all. That means,
while you are making your choices udev won't do anything with the
device, it will not probe it, not send out uevents and so on.

Just keep the lock as long as you aren't done.

> > 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.
>
> Yes, but then it reads the disk and auto mounts a partition just because
> someone ran parted print.  Printing the partition table should not
> trigger auto mount.

NO!

I don't know parted, but why would it open device for *WRITE* if it
only wants to show contents of it? It should open it for *READ* then,
and thus not trigger any events.

> Hrm... now that I think about it, why does a CHANGE event trigger auto
> mount?  Shouldn't that only be done on ADD?

No. CHANGE and ADD are both "positive" events that indicate the device
exists now. We generally want that most apps and rules treat
"positive" events the same way.

Lennart

--
Lennart Poettering, Berlin