On Sun, Nov 09, 2014 at 10:30:25PM +0100, Helge Kreutzmann wrote:
>
> Thanks for the explanation, but would there be a way to figure out
> this second process? I tried fuser and lsopen, both to no avail (but
> I've might have missed the right set of options, of course).
Is there any chance that you might be using mount namespaces or bind
mounts? Are you using LXC, or something like schroot which might be
doing this on your behalf without knowing it? If so, it might be that
although you *think* you've unmounted the file system, but in fact
it's still mounted. Try checking /proc/fs/ext4 and see if you see the
device-mapper node corresponding to /dev/system_vg/video_lv. If it's
there, then you probably have some mount namespace where the file
system is mounted.
Unfortunately depending on which namespaces are in use, trying to
figure out what still has the file system mounted can be a bit of a
mess. If you're not using pid namespaces, you coulld look at
/proc/<pid>/mounts for every single pid in the system, and see if one
or more processes has a /proc/<pid>/mounts file that has the file
system mounted.
As you'll see, /proc/mounts is symlink of /proc/self/mounts, so that
just shows you the file systems mounted in your current shell's mount
namespace. So you should of course check that, but just because you
don't see the device there, it doesn't guarantee that the file system
isn't mounted.
And of course, if you have pid namespaces enabled, and something has
set up separate pid namespaces, then /proc/* won't enumerate all of
the processes in the system, and for the same reason, fuser and lsof,
which works by examining all of the open file descriptors using
/proc/<pid>/fds/*, will also not work.
The other thing to consider is if you've created any LVM snapshots;
that will also pin a block device:
# lvcreate -s -L 5G -n build-snap heap/build
# dmsetup ls --tree
...
heap-build--snap (252:15)
├─heap-build--snap-cow (252:17)
│ └─ (8:16)
└─heap-build-real (252:16)
└─ (8:16)
...
heap-build (252:10)
└─heap-build-real (252:16)
└─ (8:16)
Any of course, if a device is part of MD raid set, that will also
cause an open with O_EXCL to fail. So there are a number of different
reasons that an O_EXCL open can fail, and all you can do is to check
all of them, and some of them don't have a simply way of testing.
Sorry.... I'm actually not all that found with how the container folks
have implemented namespaces in the kernel, because they are not very
transparent since various namespaces are not first class named
objects, and so there is no way to actually list or name them all.
Regards,
- Ted
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
