On Fri, 17.07.15 12:23, Ben Gamari ([email protected]) wrote:

> Mantas Mikulėnas <[email protected]> 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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to