[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