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
On Mon, 27.07.15 21:32, Ben Gamari (b...@smart-cactus.org) wrote: > 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. Hmm, this might just be confusion because the /dev/pts/8 device is outside of the namespace of the container. The kernel cannot show the path hence it shows "/8" instead, the path relative to the specific fs of that file, which is the devpts instance of the host. If you do "echo foo > /proc/self/fd/1", does that ger properly echoed to your pty? If so, you can safely ignore this issue... Lennart -- Lennart Poettering, Red Hat ___ 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
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: > > > >> 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 I think you forgot to add a footnote there... Lennart -- Lennart Poettering, Red Hat ___ 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
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? Lennart -- Lennart Poettering, Red Hat ___ 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
On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote:
> 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?
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
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
On Fri, 17.07.15 10:22, Ben Gamari (b...@smart-cactus.org) wrote:
> 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,
Hmm, such an old container payload is always problematic. Old distros
are not prepared to run in a container context, the differences are
too big.
In fact, I'd recommend running no OSes in contaienrs which do not
support this spec:
https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/
>
> $ 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.
Humm, this sounds like serious bug. Which nspawn version are you
running on the host? Note that upstream we focus on more recent
upstream versions of systemd only, please report issues with older
systemd versions downstream only.
Can you strace nspawn to see where the /7 comes from?
> Am I correct in assuming that this is not expected behavior? What am I
> missing here?
Nope, certainly not. It should point to /dev/pts/1.
Lennart
--
Lennart Poettering, Red Hat
___
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
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
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 wrote:
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?
___
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
