On Fri, Nov 05, 2004 at 12:03:21PM +0100, Bj�rn Steinbrink wrote: > On Fri, 5 Nov 2004 03:51:31 +0100 > Bj�rn Steinbrink <[EMAIL PROTECTED]> wrote: > > > > why not do it this way: > > > > > > 1. get a new namespace > > > 2. create the vfsmount (for example via --bind) > > > 3. pivot_root (or similar, maybe new cmd?) to the vfsmount > > > 4. cleanup the namespace (remove host stuff) > > > 5. do all required/listed mounts inside that namespace > > > 6. create the context > > > > > > > I've found an easy way to get a clean namespace using lazy mounts. A > > short bash script + description can be found at > > http://doener.homeip.net/doener/vserver/ > > (be careful with that, it's just a quick hack!) > > > > Pros: > > Mounting of the whole vserver mount tree happens using host tools. > > No / overlay mount. > > Namespace is completely clean, not even the rootfs mount is there. > > chdir("..") trick is not possible (dunno about fd exchange). > > Should be easy to integrate with the current alpha tools. > > > > Cons: > > chroot(1) must not be on a separate partition. > > Once inside the namespace currently there's no access to the host's > > binaries (i'm working on that, maybe i can do something with > > vc_set_namespace/vc_enter_namespace...) > > [whatever you dislike about it/i missed] > > > > HUGE con: > It seems to create stale mounts that are completely out of reach and > cannot be unmounted without a reboot. The problem is this: > mount -n --bind $2 $2 > cd $2 > umount -n -l $2 > mount -n -t proc none tmp > > after cd $2 our pwdmnt is the bind'ed mount. Then that mount is > unmounted. It is instantly detached and thus there's no reference to it > in the namespace anymore. Once we change our pwd above that mount, it's > out of reach. Normally, it would be unmounted now and everything's fine. > But in our case, we mount something below this unreachable mount. Thus > the mount is busy and can't be unmounted after we left it. > So we lost any reference to the bind mount and to the proc mount on the > bind mount and so we have no way to unmount it. > Even if we do this in another namespace, the stale mounts will never go > away, since on namespace destruction, mounts are searched starting from > the root mount, and from there no way leads to our problematic mounts. > > Question: Could this be considered a kernel bug? I'd say the kernel > should take care so that you're unable to create such a situation.
somehow I can hear Al's comment: "if you use vfsmagic you better know what you are doing." and yes, it is probably a kernel issue ... best, Herbert > Bjoern > _______________________________________________ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
