[lxc-devel] Strange problem (stray mounts) with lxc-create...

S.Çağlar Onur caglar at 10ur.org
Sat Oct 19 17:43:16 UTC 2013


Hey,

I upgraded my ubuntu box to saucy (using do-release-upgrade tool) minutes
ago and I realized that this very same problem starts to happen on my
system as well (using lxc at master).

[caglar at oOo:~] lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 13.10
Release: 13.10
Codename: saucy

[caglar at oOo:~] uname -a
Linux oOo 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

[caglar at oOo:~] mount > old

[caglar at oOo:~] sudo lxc-create -n t -t busybox
setting root password to "root"
Failed to change root password

[caglar at oOo:~] mount > new

[caglar at oOo:~] diff -u old new
--- old 2013-10-19 13:32:41.701250989 -0400
+++ new 2013-10-19 13:32:47.629178285 -0400
@@ -23,3 +23,4 @@
 cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)
 systemd on /sys/fs/cgroup/systemd type cgroup
(rw,noexec,nosuid,nodev,none,name=systemd)
 gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
(rw,nosuid,nodev,user=caglar)
+/lib on /usr/lib/x86_64-linux-gnu/lxc/rootfs/lib type none (rw,bind)

[caglar at oOo:~] mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs
(rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)
systemd on /sys/fs/cgroup/systemd type cgroup
(rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
(rw,nosuid,nodev,user=caglar)
/lib on /usr/lib/x86_64-linux-gnu/lxc/rootfs/lib type none (rw,bind)

[caglar at oOo:~] cat  /proc/self/mountinfo
15 20 0:14 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
17 20 0:5 / /dev rw,relatime - devtmpfs udev
rw,size=1015004k,nr_inodes=253751,mode=755
18 17 0:11 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts
rw,gid=5,mode=620,ptmxmode=000
19 20 0:15 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs
rw,size=205016k,mode=755
20 1 8:1 / / rw,relatime - ext4
/dev/disk/by-uuid/0f36b909-f4b8-434f-a8d2-cbdce7f5ddc9
rw,errors=remount-ro,data=ordered
22 15 0:16 / /sys/fs/cgroup rw,relatime - tmpfs none rw,size=4k,mode=755
23 15 0:17 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
24 15 0:6 / /sys/kernel/debug rw,relatime - debugfs none rw
25 15 0:10 / /sys/kernel/security rw,relatime - securityfs none rw
26 19 0:18 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs none
rw,size=5120k
27 19 0:19 / /run/shm rw,nosuid,nodev,relatime - tmpfs none rw
28 19 0:20 / /run/user rw,nosuid,nodev,noexec,relatime - tmpfs none
rw,size=102400k,mode=755
29 22 0:21 / /sys/fs/cgroup/cpuset rw,relatime - cgroup cgroup
rw,cpuset,clone_children
30 15 0:22 / /sys/fs/pstore rw,relatime - pstore none rw
31 22 0:23 / /sys/fs/cgroup/cpu rw,relatime - cgroup cgroup rw,cpu
32 22 0:24 / /sys/fs/cgroup/cpuacct rw,relatime - cgroup cgroup rw,cpuacct
33 22 0:25 / /sys/fs/cgroup/memory rw,relatime - cgroup cgroup rw,memory
34 22 0:26 / /sys/fs/cgroup/devices rw,relatime - cgroup cgroup rw,devices
35 22 0:27 / /sys/fs/cgroup/freezer rw,relatime - cgroup cgroup rw,freezer
36 22 0:28 / /sys/fs/cgroup/blkio rw,relatime - cgroup cgroup rw,blkio
37 22 0:29 / /sys/fs/cgroup/perf_event rw,relatime - cgroup cgroup
rw,perf_event
38 22 0:30 / /sys/fs/cgroup/hugetlb rw,relatime - cgroup cgroup rw,hugetlb
39 22 0:31 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime -
cgroup systemd rw,name=systemd
40 28 0:32 / /run/user/1000/gvfs rw,nosuid,nodev,relatime - fuse.gvfsd-fuse
gvfsd-fuse rw,user_id=1000,group_id=1000

Let me know if you need anything else.

Cheers,


On Mon, Oct 14, 2013 at 5:34 PM, Michael H. Warfield <mhw at wittsend.com>wrote:

> On Wed, 2013-10-09 at 09:50 -0500, Serge Hallyn wrote:
> > > lxc-create -n Ubuntu-test -t ubuntu
> > >
> > > Bingo...
> > >
> > > /dev/mapper/fedora-root on /usr/lib64/lxc/rootfs type ext4
> (rw,relatime,seclabel,data=ordered)
> > >
> > > Why is lxc-create even creating that mount?  I don't see any reason for
> >
> > Check lxccontainer.c:785 and line 805.  We call bdev_mount() in case its
> > a blockdev.  In the case of a dir-backed container we still end up doing
> > a bind mount of the rootfs.
>
> I'm not seeing the first of those ERROR calls show up in the output.
> The second one is a strange bird...
>
> I never see this one hit:
>
> ERROR("error unsharing mounts");
>
> I DO, however, see this message (assuming it's a unique message that may
> not be duplicated in other messages):
>
> ERROR("Error mounting rootfs");
>
> However, that appears to only occur if I tried to create a previous
> container under the same name and that failed (and then I have a
> dangling mount that seems to generate the failure).  I can reproduce
> that error by creating a container under a name "Foo" and then
> immediately destroying it and then attempting to create a new one with
> the same name (without running the umounts first).  Then I see that
> "Error mounting rootfs" until I run the umount command first.
>
> > > it.  We're never running the container in lxc-create.  Running
> > > "umount /usr/lib64/lxc/rootfs" clears it and we're off to the races
> > > again.
> > >
> > > If I were to venture a WAG (Wild Ass Guess) some initialization code is
> > > creating that bind mount that is not needed and that the cleanup code
> in
> > > lxc-create is unaware of.  But I haven't gone to the trouble of trying
> > > to track the code down yet.
> >
> > Now is your / still MS_SHARED?  The bdev create and templates
> > run in a private namespace, but if MS_SHARED then the mounts get
> > bounced back to host.  Maybe we need to manually set MS_PRIVATE every
> > time after doing an unshare() in lxc code.
> >
>
> --
> 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!
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
>


-- 
S.Çağlar Onur <caglar at 10ur.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131019/4e742fca/attachment.html>


More information about the lxc-devel mailing list