[systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container

[Lennart Poettering]

On Fri, 17.07.15 12:23, Ben Gamari (ben at smart-cactus.org) wrote:

> Mantas Mikulėnas <grawity at gmail.com> writes:
> 
> > 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.
> >
> Fair enough. In that case perhaps the lack of job control is due to,
> 
>     bash: cannot set terminal process group (-1): Inappropriate ioctl for device
> 
> Indeed looking at jobs.c, it seems that bash tries to move the fd for
> its tty to a high number (255 in this case) and will then try using it
> to set the terminal process group. I see this pretty clearly in the
> strace output,
> 
>     $ sudo systemd-nspawn -D$(realpath centos6.5-amd64) /usr/bin/strace -f -- bash -i
>     ...
>     19617 dup2(3, 255)                      = 255
>     19617 close(3)                          = 0
>     19617 ioctl(255, TIOCGPGRP, [32695])    = -1 ENOTTY (Inappropriate ioctl for device)
>     19617 ioctl(255, TIOCGPGRP, [32695])    = -1 ENOTTY (Inappropriate ioctl for device)
>     19617 fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 7), ...}) = 0
>     19617 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb741b8c000
>     19617 write(2, "bash: cannot set terminal proces"..., 77) = 77
> 
> Note how both of the ioctls failed with ENOTTY, which according to the
> tcgetpgrp manpage means,
> 
>     The calling process does not have a controlling terminal, or it has one
>     but it is not described by fd, or, for tcsetpgrp(), this controlling
>     terminal is no longer associated with the session of the calling
>     process.
> 
> Why might this be the case? Does nspawn prevent the process from getting
> a controlling tty?

The pty setup code changed in nspawn evrsions, hence it is important
to say which version you are running?

Lennart

-- 
Lennart Poettering, Red Hat