[lxc-devel] [PATCH] Support MS_SHARED /

Michael H. Warfield mhw at WittsEnd.com
Wed Jan 16 16:22:31 UTC 2013


Serge,

Revisiting an earlier remark...

On Thu, 2012-12-20 at 09:03 -0600, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at 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.

Were you still looking at this?  Currently, with the MS_SHARED patch
work in 0.9.0, the mount table is pretty ugly and running "df" in a
container is really ugly...

This is a CentOS 6 container on a my Fedora 17 host (currently running a
version of systemd that uses MS_SHARED) with the latest code from
staging:

[mhw at vault ~]$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs               719486924 633061240  49877864  93% /
/dev/sda2            719486924 633061240  49877864  93% /
df: `/var/lib/nfs/rpc_pipefs': No such file or directory
devtmpfs             719486924 633061240  49877864  93% /dev
tmpfs                  1795044         0   1795044   0% /dev/shm
df: `/dev/mqueue': No such file or directory
df: `/dev/hugepages': No such file or directory
df: `/sys/fs/cgroup/systemd': No such file or directory
df: `/sys/fs/cgroup/cpuset': No such file or directory
df: `/sys/fs/cgroup/cpu,cpuacct': No such file or directory
df: `/sys/fs/cgroup/memory': No such file or directory
df: `/sys/fs/cgroup/devices': No such file or directory
df: `/sys/fs/cgroup/freezer': No such file or directory
df: `/sys/fs/cgroup/net_cls': No such file or directory
df: `/sys/fs/cgroup/blkio': No such file or directory
df: `/sys/fs/cgroup/perf_event': No such file or directory
df: `/run': No such file or directory
tmpfs                719486924 633061240  49877864  93% /media
df: `/export': No such file or directory
/dev/sdb1            719486924 633061240  49877864  93% /srv
/dev/sda5            719486924 633061240  49877864  93% /home
/dev/sda1            719486924 633061240  49877864  93% /boot
df: `/usr/lib64/lxc/rootfs': No such file or directory
df: `/usr/lib64/lxc/rootfs': No such file or directory
/dev/sdb1            719486924 633061240  49877864  93% /
/dev/sda5             23220700  17445188   4595968  80% /srv/shared
none                   1795044         0   1795044   0% /dev/shm
[mhw at vault ~]$ 

This is a Fedora 17 container on that same host...

[mhw at alcove ~]$ df
df: ‘/var/lib/nfs/rpc_pipefs’: No such file or directory
df: ‘/sys/fs/cgroup/cpuset’: No such file or directory
df: ‘/sys/fs/cgroup/cpu,cpuacct’: No such file or directory
df: ‘/sys/fs/cgroup/memory’: No such file or directory
df: ‘/sys/fs/cgroup/devices’: No such file or directory
df: ‘/sys/fs/cgroup/freezer’: No such file or directory
df: ‘/sys/fs/cgroup/net_cls’: No such file or directory
df: ‘/sys/fs/cgroup/blkio’: No such file or directory
df: ‘/sys/fs/cgroup/perf_event’: No such file or directory
df: ‘/export’: No such file or directory
df: ‘/usr/lib64/lxc/rootfs’: No such file or directory
df: ‘/usr/lib64/lxc/rootfs’: No such file or directory
Filesystem     1K-blocks      Used Available Use% Mounted on
rootfs         719486924 633061300  49877804  93% /
/dev/sda2      719486924 633061300  49877804  93% /
devtmpfs             100         0       100   0% /dev
tmpfs            1795044         0   1795044   0% /dev/shm
tmpfs            1795044         0   1795044   0% /sys/fs/cgroup
tmpfs            1795044       748   1794296   1% /run
tmpfs          719486924 633061300  49877804  93% /media
/dev/sdb1      719486924 633061300  49877804  93% /srv
/dev/sda5      719486924 633061300  49877804  93% /home
/dev/sda1      719486924 633061300  49877804  93% /boot
/dev/sdb1      719486924 633061300  49877804  93% /
none                 100         0       100   0% /dev
none             1795044         0   1795044   0% /dev.tmp
/dev/sda5       23220700  17445188   4595968  80% /srv/shared
tmpfs            1795044         0   1795044   0% /dev/shm
tmpfs            1795044       748   1794296   1% /run
tmpfs            1795044         0   1795044   0% /sys/fs/cgroup
tmpfs            1795044         0   1795044   0% /tmp
[mhw at alcove ~]$

Even some of the ones that didn't error out have incorrect information
in them (/srv, /media, /home, /boot all wrong).

> 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.

How bad is this breakage in regards to that then?

> Michael, can you show me your /proc/self/mountinfo in a f18
> box?

Regards,
Mike

> > 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.
> 
> -serge
> 
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130116/5045e228/attachment.pgp>


More information about the lxc-devel mailing list