Note that devpts also supports multiple instances – the host /dev/pts is not the same as the guest /dev/pts'en. So my guess is that your stdio is attached to a pty from the *host*. Not really sure how that breaks job control though. Also, the fd symlinks are slightly magical; they can be followed and opened even if readlink returns garbage. (For example, a socket fd or a pipe fd wouldn't even *have* a path to return, yet the /proc symlink can be opened.) So that again shouldn't cause problems. On Fri, Jul 17, 2015, 11:27 Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote: <blockquote>I have been having quite some trouble getting nspawn give me a shell with proper job control in a CentOS 6.6 guest. The problem appears to be that the nodes representing the std{out,err,in} fds in /proc are malformed, $ sudo strace -f -obad systemd-nspawn -D$(realpath centos6.5-amd64) Spawning container centos6.5-amd64 on /home/ben/vm/centos6.5-amd64. Press ^] three times within 1s to kill container. Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux: Read-only file system Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux: Read-only file system /etc/localtime is not a symlink, not updating container timezone. -bash: cannot set terminal process group (-1): Inappropriate ioctl for device -bash: no job control in this shell -bash-4.1# ls -lh /proc/self/fd total 0 lrwx------ 1 root root 64 Jul 17 04:14 0 -> /7 lrwx------ 1 root root 64 Jul 17 04:14 1 -> /7 lrwx------ 1 root root 64 Jul 17 04:14 2 -> /7 lr-x------ 1 root root 64 Jul 17 04:14 3 -> /proc/13/fd Note that fds 0, 1, and 2 all point to a non-existent /7 file. I believe this should instead point to /dev/pts/7, although strangely this does not exist either despite /dev/pts being mounted. I am running a very recent (4.1) kernel. Am I correct in assuming that this is not expected behavior? What am I missing here? </blockquote>