> On Feb. 27, 2015, 10:27 a.m., Jie Yu wrote: > > src/slave/containerizer/mesos/launch.cpp, lines 375-376 > > <https://reviews.apache.org/r/31444/diff/1/?file=876502#file876502line375> > > > > Some of my findings regarding pivot_root. It's quite subtle:) > > > > This works: > > ``` > > [vagrant@localhost ~]$ sudo unshare -m > > [root@localhost vagrant]# ls > > busybox > > [root@localhost vagrant]# mount --make-rslave / > > [root@localhost vagrant]# mount --bind busybox/ busybox/ > > [root@localhost vagrant]# mount --make-private busybox/ > > [root@localhost vagrant]# cd busybox/ > > [root@localhost busybox]# pivot_root . mnt > > ``` > > > > This does not work: > > ``` > > [root@localhost vagrant]# unshare -m > > [root@localhost vagrant]# mount --make-rslave / > > [root@localhost vagrant]# cd busybox/ > > [root@localhost busybox]# mount --bind . . > > [root@localhost busybox]# mount --make-private . > > [root@localhost busybox]# pivot_root . mnt/ > > pivot_root: failed to change root from `.' to `mnt/': Device or > > resource busy > > ``` > > Ian Downes wrote: > The first part works but doesn't enable propagation of mounts from the > host to the container, e.g., as persistent resources are added and removed by > the slave. > > I can eliminate the old_root bind mount in favor of a bind mount of the > new_root, but it must be a slave, rather than private, i.e., as you've got > but "mount --make-slave busybox/". Could you please verify that works under > your setup? > > Jie Yu wrote: > I've tested the following on fedora-20" > > Console 1: > ``` > [vagrant@localhost ~]$ sudo unshare -m /bin/bash > [root@localhost vagrant]# ls > busybox volumes > [root@localhost vagrant]# mount --make-rslave / > [root@localhost vagrant]# mount --bind /home/vagrant/busybox > /home/vagrant/busybox > [root@localhost vagrant]# cd busybox/ > [root@localhost busybox]# pivot_root . mnt > [root@localhost busybox]# chroot . /bin/sh > / # mount -t proc /proc > / # cat /proc/self/mountinfo | cut -d' ' -f 5 | grep ^/mnt | xargs umount > -l > / # cat /proc/self/mountinfo > 75 44 253:1 /home/vagrant/busybox / rw,relatime master:1 - ext4 > /dev/mapper/vg_vagrant-lv_root rw,data=ordered > 76 75 0:3 / /proc rw,relatime - proc proc rw > ``` > > Console 2: > ``` > [vagrant@localhost ~]$ ls > busybox volumes > [vagrant@localhost ~]$ sudo mount --bind volumes/volume1 busybox/mnt > ``` > > Go back to console 1: > ``` > / # cat /proc/self/mountinfo > 75 44 253:1 /home/vagrant/busybox / rw,relatime master:1 - ext4 > /dev/mapper/vg_vagrant-lv_root rw,data=ordered > 76 75 0:3 / /proc rw,relatime - proc proc rw > 47 75 253:1 /home/vagrant/volumes/volume1 /mnt rw,relatime master:1 - > ext4 /dev/mapper/vg_vagrant-lv_root rw,data=ordered > ``` > > Jie Yu wrote: > However, the above does not work on trusty64 (ubuntu)! > > Fedora-20 > ``` > [vagrant@localhost ~]$ uname -a > Linux localhost.localdomain 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 > 14:01:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > ``` > > Trusty64 > ``` > vagrant@vagrant-ubuntu-trusty-64:~$ uname -a > Linux vagrant-ubuntu-trusty-64 3.13.0-32-generic #57-Ubuntu SMP Tue Jul > 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > ``` > > Jie Yu wrote: > OK, I found out the reason. On trusty64, I have to do a `mount > --make-rshared /` in the host namespace before doing anything.
We cannot globally change something in the host... recursively changing all mounts will surely break someone's configuration somewhere. Can you try again on the trusty64 box (freshly booted) and just make the bind mount of the new root (in the container namespace) a slave mount, as I described above. Thanks! - Ian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31444/#review74382 ----------------------------------------------------------- On Feb. 25, 2015, 2:48 p.m., Ian Downes wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/31444/ > ----------------------------------------------------------- > > (Updated Feb. 25, 2015, 2:48 p.m.) > > > Review request for mesos, Chi Zhang, Dominic Hamon, Jay Buffington, and Jie > Yu. > > > Bugs: MESOS-2350 > https://issues.apache.org/jira/browse/MESOS-2350 > > > Repository: mesos > > > Description > ------- > > Optionally take a path that the launch helper should chroot to before > exec'ing the executor. It is assumed that the work directory is mounted to > the appropriate location under the chroot. In particular, the path to the > executor must be relative to the chroot. > > Configuration that should be private to the chroot is done during the launch, > e.g. mounting proc and statically configuring basic devices. It is assumed > that other configuration, e.g., preparing the image, mounting in volumes or > persistent resources, is done by the caller. > > Mounts can be made to the chroot (e.g., updating the volumes or persistent > resources) and they will propagate in to the container but mounts made inside > the container will not propagate out to the host. > > It currently assumes that at least {{chroot}}/tmp is writeable and that mount > points {{chroot}}/{tmp,dev,proc,sys} exist in the chroot. > > This is specific to Linux. > > > Diffs > ----- > > src/slave/containerizer/mesos/launch.hpp > 7c8b535746b5ce9add00afef86fdb6faefb5620e > src/slave/containerizer/mesos/launch.cpp > 2f2d60e2011f60ec711d3b29fd2c157e30c83c34 > > Diff: https://reviews.apache.org/r/31444/diff/ > > > Testing > ------- > > Manual testing only so far. This is harder to automate because we need a > self-contained chroot to execute something in... Suggestions welcome. > > > Thanks, > > Ian Downes > >
