[lxc-devel] possible lxc-attach problem
Serge Hallyn
serge.hallyn at ubuntu.com
Fri Feb 28 17:00:29 UTC 2014
Quoting S.Çağlar Onur (caglar at 10ur.org):
> Hi,
>
> I was working on Fedora 20 system to investigate a possible go
> bindings bug and realized that lxc-attach is not working as I
> expected. [1] is some output captured with LXC at master on top of Fedora
> 20 running a Fedora 20 container. I haven't tested this on my ubuntu
> machine and I'm wondering if any of you have more insight.
>
> [1] http://paste.ubuntu.com/7008604/
Yeah, so these are the things that happen with a shared /.
1. you get an extra set of mounts in /proc/self/mounts. I'm not yet
sure why. In chroot_into_slave(), we
. bind-mount /usr/lib/lxc to itself
. make it slave
. mount a tmpfs under /usr/lib/lxc
. mkdir /usr/lib/lxc/root there
. rbind-mount / under /usr/lib/lxc/root
. mark that slave
. chroot to /usr/lib/lxc/root
Then we proceed with the usual mounts setup. This process is
meant to address to problems:
a. you can't pivot if your old /, your old /'s mnt_parent,
or your new /'s mnt_parent is shared
b. you can't pivot if your current root is ramfs (or, has no parent
mount)
Simply marking / MS_SLAVE|MS_REC instead of doing chroot_into_slave
at all appears to fix the problem in some cases, but mysteriously fails
in other cases.
2. lxc-attach puts you into the host version of a directory. If
attach first chroots into the /proc/init_pid/root, then it works
correctly.
It seems to me these are the right things to do, but they'll take
some experimentation with the many possible hosts:
1. If / is not shared, do nothing
2. if / is shared, and is not the ramfs, then remount MS_SLAVE|MS_REC
3. if / is ramfs, then do the chroot_into_slave
More information about the lxc-devel
mailing list