[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