Unexpected "[Errno 2] No such file or directory"

[hartwork]

A chroot I was previously able to chroot into just turned unenterable.
(The connection died and since there was no tmux open to re-enter, I killed pychroot's offspring processes.)

Now entering fails like this:

# pychroot wheezy_chroot/ /bin/bash 
[Errno 2] No such file or directory

# ls -l wheezy_chroot/bin/bash
-rwxr-xr-x 1 root root 975488 Sep 25  2014 wheezy_chroot/bin/bash

It turns out the problem is actually piles of letfover mounts from previous runs. To give an excerpt of findmnt output:

├─/root/wheezy_chroot/dev                     udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ ├─/root/wheezy_chroot/dev/pts               devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/root/wheezy_chroot/dev/shm               tmpfs      tmpfs      rw,nosuid,nodev
│ ├─/root/wheezy_chroot/dev                   udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ ├─/root/wheezy_chroot/dev/pts             devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ ├─/root/wheezy_chroot/dev/shm             tmpfs      tmpfs      rw,nosuid,nodev
│ │ ├─/root/wheezy_chroot/dev                 udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ ├─/root/wheezy_chroot/dev/pts           devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ ├─/root/wheezy_chroot/dev/shm           tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ ├─/root/wheezy_chroot/dev               udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ ├─/root/wheezy_chroot/dev/pts         devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ ├─/root/wheezy_chroot/dev/shm         tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ ├─/root/wheezy_chroot/dev             udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ │ ├─/root/wheezy_chroot/dev/pts       devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ │ ├─/root/wheezy_chroot/dev/shm       tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ │ ├─/root/wheezy_chroot/dev           udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ │ │ ├─/root/wheezy_chroot/dev/pts     devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ │ │ ├─/root/wheezy_chroot/dev/shm     tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ │ │ ├─/root/wheezy_chroot/dev         udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ │ │ │ ├─/root/wheezy_chroot/dev/pts   devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ │ │ │ ├─/root/wheezy_chroot/dev/shm   tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ │ │ │ └─/root/wheezy_chroot/dev       udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755

This is on Debian wheezy btw. I didn't do any mounting inside or outside the chroot otherwise, myself.

[radhermit]

This sounds like issue #12. I'm planning to fix it up for TERM/SIGINT, obviously I can't cleanup anything if you SIGKILL pychroot.

[radhermit]

Also if that findmnt output is from the regular namespace perhaps Debian allows mount event propagation by default while Gentoo doesn't. Guess I should fire up some other distros and test things out.

We probably should make sure the mounts in the chroot are slave mounts by default so changes in the outer namespace can affect the chroot, but things in the chroot don't propagate back.

[hartwork]

if that findmnt output is from the regular namespace

Yes, Debian jessie to be precise.

allows mount event propagation by default while Gentoo doesn't

How would I query that configuration? Where is that configured in Gentoo?

We probably should make sure the mounts in the chroot are slave mounts by default so changes in the outer namespace can affect the chroot, but things in the chroot don't propagate back.

Sounds good to me.

[radhermit]

Gentoo doesn't do anything with the main root mount so that means it is not sharing by default. Of course, if you have "shared" or similar mount options in fstab, then it will be shared by default.

For other distros, it depends either on fstab settings or on whatever is handling mounting the initial root partition. For example, systemd-based systems have had shared root mounts for almost 3 years.

[radhermit]

I should also note, if things are working properly you should never see chroot mounts in the host mount namespace. I'll try to toss up a quick patch later today you can test out that will just turn off chroot mount propagation back to the main namespace which should fix the main issue.

[hartwork]

I suppose you're referring to using a Linux namespace. Good idea.

[radhermit]

That should do it, I tested by doing:

sudo mount --make-rshared /
sudo ./pychroot ~/chroot /bin/bash

And confirmed that the chroot mounts were leaking to the host before the fix. With the fix, the chroot mounts don't propagate back up.

Next release will probably come in a few days and will require a new snakeoil version.