when an `lvchange -an ...` fails, lvm tries to give a better reason than
"is currently in use" by looking at /sys/dev/block/.../holders and
/proc/self/mountinfo when --verbose is given.

it was pointed out to me that i could look at /proc/*/mountinfo as well,
and indeed i found `/sbin/cgmanager --daemon-mname=systemd`.

given cgroups are in wide use today, lvm should take its helpfulness a
little further and look at /proc/*/mountinfo as well for possible mount
locations, and display which processes are involved so the user has a
realistic chance to find the holder of the mount.


note that lvm is not the only program that should do that, but the only
program that does *something* like this at all. (before i tried
`lvchange -an`, i originally wanted to fsck the block device or to mount
it somewhere different, and those programs didn't even try to tell me
where the device is mounted). ideally, in my opinion, it should not be
lvm2 to drill down to the reasons of the device being unavailable, but a
generic `who-uses` tool that would then be used or suggested by lvm,
mount or fsck in case of a failure.

I'd say the best "who-uses" tool in this case is "lsblk" - it's directly
a part of util-linux which is everywhere and it shows quickly the block
device tree as well as mount status (it just looks at sysfs info and
provides it in nice human readable form, machine readable form is also
possible though for use in scripts). LVM itself already uses this tool
within helper "blkdeactivate" script that deactivates tree of DM/LVM
devices.

so you see a chance that lvm could delegate the diagnoistic messages for
where to find the offending mount point to lsblk (or dmsetup or findmnt, but
lsblk is probably the most suitable of those)?

if yes, i'd open a similar bug against util-linux (lsblk does not do any
better than lvm in container conditions at the moment), and keep this
only open to track lvm's progress on delegating to lsblk.

best regards
chrysn

We've recently opened an LVM2 upstream bug to check for holders across
containers (https://bugzilla.redhat.com/show_bug.cgi?id=1181029). Still,
this will just stop LVM from doing certain actions (this support in LVM
will be only LVM specific for its own purposes if it detects the
device is in use). But LVM itself won't provide you as much info here
as lsblk could.

So yes, I think lsblk should be enhanced here a bit as well to take
containers more into account if it doesn't do so currently. This way
more people can make use of this info and they won't need to look
for it themselves in various places all around the system.