Description of problem: The addition of the 'MS_REC' flag in the util-linux-2.20-mount-rec.patch used in util-linux-2.20.1-2.3 breaks lxc containers that share their host root file system and create pseudo tty instances. Version-Release number of selected component (if applicable): util-linux-2.20.1-2.3 lxc-0.7.5-1 How reproducible: Can be reproduced on demand. Steps to Reproduce: 1. Create a 'lxc.conf' file containing the following single line: lxc.pts = 128 2. Issue the following command to create a container running a bash shell: $ sudo lxc-execute -f lxc.conf --name test bash Actual results: $ sudo lxc-execute -f lxc.conf --name test bash lxc-execute: Device or resource busy - failed to umount 'dev/pts' lxc-execute: failed to setup the new pts instance lxc-execute: failed to setup the container lxc-execute: invalid sequence number 1. expected 2 lxc-execute: failed to spawn 'test' Expected results: $ sudo lxc-execute -f lxc.conf --name test bash [root@demo ~]# Additional info: I downgraded to the previous version of util-linux (2.20.1-2) in order to trace the problem back to a specific package. After running some tests I isolated the issue to the inclusion of the util-linux-2.20-mount-rec.patch in util-linux-2.20.1-2.3 which was not present in util-linux-2.20.1-2. Removing the patch from the spec file or modifying the patch to not include the 'MS_REC' flags, which is effectively the same as removing the patch, remedies the issue. I do not have enough knowledge of libmount to understand the purpose of the patch or how it relates to lxc usage of /dev/pts.
The MS_REC flag is required for recursive mount operations -- for example --rbind, --make-rshare, etc. It seems that something in lxc containers depends on the old *broken* implementation where MS_REC has been incorrectly removed. It would be nice to identify the mount usage (or command) in lxc with MS_SHARED, MS_SLAVE, MS_UNBINDABLE or MS_PRIVATE operations. The util-linux-2.20-mount-rec.patch cannot be removed.
On Fedora 17/x86_64, I cannot reproduce the problem: # rpm -q lxc lxc-libs util-linux lxc-0.7.5-1.fc17.x86_64 lxc-libs-0.7.5-1.fc17.x86_64 util-linux-2.21.2-2.fc17.x86_64 # uname -r 3.4.4-5.fc17.x86_64 # echo "lxc.pts = 128" > /tmp/lxc.conf # lxc-execute -f /tmp/lxc.conf --name test /usr/bin/bash # ps ax PID TTY STAT TIME COMMAND 1 ? S 0:00 /usr/lib64/lxc/lxc-init -- /usr/bin/bash 2 ? S 0:00 /usr/bin/bash 214 ? R+ 0:00 ps ax As far as I can see, lxc uses MS_REC only while mounting the rootfs (in src/lxc/conf.c): static int mount_rootfs_dir(const char *rootfs, const char *target) { return mount(rootfs, target, "none", MS_BIND | MS_REC, NULL); }
Need more information on how to reproduce and possibly report this upstream.
Also cannot reproduce on F16/x86_64: # rpm -q lxc lxc-libs util-linux lxc-0.7.5-1.fc16.x86_64 lxc-libs-0.7.5-1.fc16.x86_64 util-linux-2.20.1-2.3.fc16.x86_64 # uname -r 3.4.4-4.fc16.x86_64 # echo "lxc.pts = 128" > /tmp/lxc.conf # lxc-execute -f /tmp/lxc.conf --name test /bin/bash # ps ax PID TTY STAT TIME COMMAND 1 ? S 0:00 /usr/lib64/lxc/lxc-init -- /bin/bash 2 ? S 0:00 /bin/bash 94 ? R+ 0:00 ps ax So, closing.