From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 17 Aug 2005 - 19:32:06 BST
On Wed, Aug 17, 2005 at 06:53:05PM +0200, lukas.rueegg [pixworx multimedia] wrote:
> we have quite a special setup with debian sarge, vanilla kernel
> 188.8.131.52 vserver 2.0stable, drbd, lvm2, heartbeat, etc. and got to
> a very special problem which we now broke down to the last point of
> failure, which seems to be vserver.
heh, seems, but actually it is only a catalyst (see below)
> the test setup for reproduction is quite simple:
> - set up any 'removable' block device (we tested with both drbd 0.7 and
> lvm2), mkreiserfs it and mount it.
> - start any vserver (which DOES NOT reside on this block-device).
> - umount the filesystem on the block device (which happens without any
> - try to remove/deactivate the block-device:
> -- drbd:
> lru_at_granit:~$ sudo drbdadm secondary drbd1
> ioctl(,SET_STATE,) failed: Device or resource busy
> Someone has opened the device for RW access!
> Command '/sbin/drbdsetup /dev/drbd1 secondary' terminated with exit code 20
> drbdadm aborting
> -- lvm2:
> lru_at_granit:~$ sudo lvchange -van /dev/VGsda8/LVsda8
> Using logical volume(s) on command line
> Deactivating logical volume "LVsda8"
> Found volume group "VGsda8"
> LV VGsda8/LVsda8 in use: not removing
> we think, this would also happen to any other removable device like an
> usb-stick or whatever...
> - stop the running vserver
> - try again to remove/deactivate the block-device and be surprised: it
> - there are also no problems if the filesystem is mounted while the
> vserver is already running.
> - there seems also no problem with the plain chroot environment, which
> we tested.
> conclusion: it seems that vserver somehow gets it's hands into this
> filesystem and locks it down. surprisingly, the umount works perfectly
> and any lsof or fuser-command (also in chcontext 1) doesn't give any
no, vserver does not get it's hands on the filesystem, and
you can easily (well probably not so easily) reproduce the
issue without the vserver patches ...
> does anyone has any hint about how this could be solved?
the issue is the following:
1) you mount some filesystem on the host
2) you create a private namespace (a copy of the host
namespace, happens implicitely when you start the
3) you unmount the filesystem on the host (but not
in the guest namespace of course)
you can solve the issue by:
a) not mounting removeable media on the host before
starting a guest
b) unmounting the filesystem in _all_ namespaces
c) using the cleanup feature we added to the kernel
(please discuss this with Enrico)
> thank you very much
> pixworx multimedia
> lukas rueegg
> ch-8005 zurich
> [ Why is 6 scared of 7? Because 7 8 9. ]
> Vserver mailing list
Vserver mailing list