Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Lennart Poettering writes: > On Mon, 27.07.15 21:08, Ben Gamari (b...@smart-cactus.org) wrote: > >> Lennart Poettering writes: >> >> > On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: >> > >> >> >> >> Ahh, of course. This is a Debian sid machine, so systemd 221. >> > >> > That's pretty recent. Any chance you can strace this, checking where >> > this "/7" file comes from? >> > >> Sure. >> >> This Gist [1] is the output from > > I think you forgot to add a footnote there... > Indeed I did. Thanks. Cheers, - Ben [1] https://gist.github.com/bgamari/e39ae645a84df670e5c4 signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Lennart Poettering writes: > On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: > >> Lennart Poettering writes: >> >> > On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote: >> > >> snip >> >> >> 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? >> > >> Ahh, of course. This is a Debian sid machine, so systemd 221. > > That's pretty recent. Any chance you can strace this, checking where > this "/7" file comes from? > Sure. This Gist [1] is the output from $ strace -f -ohi systemd-nspawn --personality=x86-64 -D$MY_CHROOT and running `ls /proc/self/fd -lh` in the resulting shell. This produced, $ ls /proc/self/fd -lh total 0 lrwx-- 1 root root 64 Jul 27 15:02 0 -> /8 lrwx-- 1 root root 64 Jul 27 15:02 1 -> /8 lrwx-- 1 root root 64 Jul 27 15:02 2 -> /8 lr-x-- 1 root root 64 Jul 27 15:02 3 -> /proc/13/fd Where the links to /8 were broken. Cheers, - Ben signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Lennart Poettering writes: > On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote: > snip >> 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? > Ahh, of course. This is a Debian sid machine, so systemd 221. Thanks for your help! Cheers, - Ben signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Mantas Mikulėnas 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?
Cheers,
- Ben
[1]
http://stackoverflow.com/questions/11821378/what-does-bashno-job-control-in-this-shell-mean
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
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?
Cheers,
- Ben
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
