Hey Serge, I saw your patch and your comment about being out till the 2nd. I'm also out until the 27th myself and away from my clusters.
On Thu, 2012-12-20 at 09:03 -0600, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
> > On 12/20/2012 06:58 AM, Serge Hallyn wrote:
> ...
> > /proc/mounts in the container will also end up being polluted by all the
> > mount points from the host, this in itself doesn't cause any big
> > problem, though the container will try (and fail) to unmount all of those.
> > Is there anything we can do to improve that situation or is that a side
> > effect of MS_SHARED that we can't workaround on our end?
> I think it's actually a side effect of pivot-root after chroot. You
> have /orig_root/foo/chroot_root/path/new_pivot/put_old. Then you
> chroot to /orig_root/foo/chroot_root. When you then pivot to
> /path/new_pivot, what ends up in put_old is /orig_root/foo/chroot_root.
> I'm actually not sure you can trim the mounts which were under
> /orig_root. We could figure out ones they are by following the chain
> of mount ids in /proc/self/mountinfo, but we can't reach them to umount
> them.
> It's much like how when you boot a livecd, you see things like
> the rootfs on / as well as /cow on /. You can't reach the rootfs
> which is parent of the /cow on / any more, but it's in the mounts
> table.
> Now I tested, and with a simple setup we can use a much simpler
> patch which just does mount("", "/", NULL, MS_SLAVE|MS_REC, 0);
> for the whole of chroot_into_slave() (and skips the new umount2()
> in start.c). The container then starts, and its mounts table
> is clean.
> Where that won't work is in a livecd or any fancy raid setup,
> where your process's / has a parent which is MS_SHARED.
> Michael, can you show me your /proc/self/mountinfo in a f18
> box?
I'll look into this as soon as I'm back at the battle bridge on the 27th
and can check it out.
Once again you've gotten in just ahead of me. I was thinking about
asking where we stood on this one. This was next on my priority list to
ask about and here you are. :-)=)
> > I didn't spend much time reviewing the code itself, but it applied to my
> > local staging tree and built fine, so that's good enough for me :)
> Thanks - TBH the extra mounts are no more wrong than they are in
> a livecd, so I don't think it's a big problem. One we can address
> in January.
Concur
> -serge
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
