Re: [Vserver] can not deactivate any block device with running vserver 2.0
[EMAIL PROTECTED] (lukas.rueegg [pixworx multimedia]) writes: c) using the cleanup feature we added to the kernel (please discuss this with Enrico) enrico, we read your talk with sam and others in november '04 but didn't get any hints about the current status. is there any way of cleaning up a new namespace in the pre-start-script or generally for all namespaces available? at the moment, we are playing around with the pre-start-scripts, until now unsuccessfully... atm, manual unmounting in the *pre-start script will be the best choice. The architecture of the 'vserver' script does not allow automatic cleanup. Perhaps I will add some logic datermining and unmounting removable devices but this will be more a hack than a clean solution. I am thinking about a daemon doing the vserver startup; this daemon could be started very early, lives in its own namespace and would not be affected by changes in the main-namespace. But this daemon does not have a big priority... Enrico pgpZoE90WKlpj.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] can not deactivate any block device with running vserver 2.0
On Thu, Aug 18, 2005 at 08:14:35AM +0200, Enrico Scholz wrote: [EMAIL PROTECTED] (lukas.rueegg [pixworx multimedia]) writes: c) using the cleanup feature we added to the kernel (please discuss this with Enrico) enrico, we read your talk with sam and others in november '04 but didn't get any hints about the current status. is there any way of cleaning up a new namespace in the pre-start-script or generally for all namespaces available? at the moment, we are playing around with the pre-start-scripts, until now unsuccessfully... atm, manual unmounting in the *pre-start script will be the best choice. The architecture of the 'vserver' script does not allow automatic cleanup. Perhaps I will add some logic datermining and unmounting removable devices but this will be more a hack than a clean solution. I am thinking about a daemon doing the vserver startup; this daemon could be started very early, lives in its own namespace and would not be affected by changes in the main-namespace. But this daemon does not have a big priority... well, it would solve a bunch of issues at once, but it would probably run into the same problems once it is restarted, no? maybe we should improve the 'cleanup' of the guest namespace somehow, but I have absolutely no idea what your requirements in this regard are ... best, Herbert PS: guess I would appreciate some scheduled discussions via IRC or if you insist, we can do it via email ... Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] can not deactivate any block device with running vserver 2.0
hello we have quite a special setup with debian sarge, vanilla kernel 2.6.12.5 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. 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 problems) - try to remove/deactivate the block-device: -- drbd: [EMAIL PROTECTED]:~$ 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: [EMAIL PROTECTED]:~$ 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 works! - 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 results. does anyone has any hint about how this could be solved? thank you very much regards lukas. -- _ pixworx multimedia lukas rueegg ch-8005 zurich http://pixworx.ch [ Why is 6 scared of 7? Because 7 8 9. ] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
