[lxc-devel] host consoles/ttys in containers

Michael Tokarev mjt at tls.msk.ru
Sat Nov 14 12:35:41 UTC 2009


Michael Tokarev wrote:
[]
> Another problem is that lxc-start does not restore terminal
> settings, at least not always.  In particular, after running
> `lxc-start -n foo /bin/bash' and killing that bash from a
> host system, lxc-start exits but the xterm window where it
> was running is now in "raw" tty mode, and can be fixed by
> running, say, `stty sane' (note that only `kill -9' works).

Here's some more details about this.  It's an straece of
lxc-start process when I killed the process #1 in a
container (simplifed):

epoll_wait(0, {{EPOLLIN, {u32=163598736, u64=163598736}}}, 2, -1) = 1
waitpid(829, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}], 0) = 829
...
rmdir("/dev/cgroup/t0")                 = 0
unlink("/var/lib/lxc/t0/init")          = -1 ENOENT (No such file or directory)
(some leftover from ol'good days? :)

close(3)                                = 0
close(4)                                = 0
(closing container's consoles and ttys)
...
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xff894e38) = -1 ENOTTY (Inappropriate ioctl for device)

But the thing is that here, fd#0 is something else indeed:

lxc-start 1737 root    0u  0000                0,7       0    365 anon_inode
lxc-start 1737 root    1u  unix 0xffff88021510a180           6161 socket
lxc-start 1737 root    2u   CHR              136,8             11 /dev/pts/8
lxc-start 1737 root    3r   CHR                5,2            888 /dev/ptmx

only fd#2 (stderr) is open to the real controlling tty.

It looks like lxc-start should dup fd#0 and use that to restore
the tty settings at exit.  Or alternatively, it should stop
using fd#0 entirely.

Thanks!

/mjt





More information about the lxc-devel mailing list