Serge, Revisiting an earlier remark...
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.
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@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@vault ~]$
This is a Fedora 17 container on that same host...
[mhw@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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
--
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
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
