lvm2 module is not noticing deactivations of logical volumes

[mvollmer]

This is caused by a2f26af.

The lvm2 module hooks into the uevent processing in a hacky way and just wants to see all of them, without ever claiming any for its own. (Maybe this should be supported by the module interface in a non-hacky way, or maybe the lvm2 module should use process_ueventinstead ofnew_object`?)

More specifically, deactivating a logical volume triggers a "remove" uevent for its block device, which causes the lvm2 module to update the Active property of the logical volume to false. Since the "remove" event doesn't reach the module anymore, Active stays true until the next trigger.

To reproduce:

# vgcreate vgroup0 /dev/sdc
# lvcreate vgroup0 -n lvol0 -l 100%FREE
# udisksctl dump | grep /lvol0: -A 2
/org/freedesktop/UDisks2/lvm/vgroup0/lvol0:
  org.freedesktop.UDisks2.LogicalVolume:
    Active:                     true

# lvchange vgroup0/lvol0 -a n
# udisksctl dump | grep /lvol0: -A 2
/org/freedesktop/UDisks2/lvm/vgroup0/lvol0:
  org.freedesktop.UDisks2.LogicalVolume:
    Active:                     true

# udevadm trigger
# udisksctl dump | grep /lvol0: -A 2
/org/freedesktop/UDisks2/lvm/vgroup0/lvol0:
  org.freedesktop.UDisks2.LogicalVolume:
    Active:                     false

Reverting a2f26af fixes this.

[tbzatek]

I see, hmm, thanks for noticing this. I wonder whether this scenario is even covered by tests.

(Maybe this should be supported by the module interface in a non-hacky way, or maybe the lvm2 module should use process_ueventinstead ofnew_object`?)

The LVM2 module needs complete rewrite to actually use the module API the right way. Sadly, no manpower to do that, it's a huge task.

I think I had a hunch something like that might be needed - see #814 and this commit in particular: 99bd6dc

[tbzatek]

Hmmm, I can't think of any elegant solution on offer right now. I'm leaning towards adding a general-uevent-hook to the module API just for the lvm2 plugin as I'd like to keep it clean, separating the quirks aside.

The commit a2f26af still makes sense to me - the logic is not to ask for a new object if the device is going away. It would mean additional checks in each module to filter out those remove uevents otherwise.

But I sense a possible deficiency in the module API - it is heavily device oriented, claiming and tracking sysfs paths. But there's apparently a need for phantom objects that have no devices associated (as there aren't any - or are there any virtual ones for deactivated LVs?) and still being able to claim new udev devices during their lifecycle. Something that we haven't though of before and which would become apparent during future lvm2 module uevent handling rewrite. Great that it's a private API.

[martinpitt]

I just investigated the F39/rawhide failures in PR #1161, which breaks the cockpit test due to this issue.