Interactive Shell. tty: Not a tty. Unable to use screen or tmux

[deibuji]

When I try to run Screen when I run an Interactive Shell, I get the following:

$ docker run -i -t base:latest /bin/bash
[...]
root@804c415fca9e:/# screen
Must be connected to a terminal
root@804c415fca9e:/# tmux
root@804c415fca9e:/# 
root@804c415fca9e:/# tty
not a tty

Although, if I create a user and getty tty, it works fine:

root@804c415fca9e:/# adduser test
root@804c415fca9e:/# getty tty

Last login: Mon May 27 22:15:24 UTC 2013 on tty
Welcome to Ubuntu 12.10 (GNU/Linux 3.8.0-19-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
test@804c415fca9e:~$ tty
/dev/tty

Screen and tmux now launch perfectly.

On the host, lxc-ps --lxc returns:

docker-admin@docker-host:~$ lxc-ps --lxc
CONTAINER    PID TTY          TIME CMD
804c415fca9ed75a14e9e45c7e19e8712e45f9693fb8abed289960cb3d6bda32  7471 pts/1    00:00:00 bash
804c415fca9ed75a14e9e45c7e19e8712e45f9693fb8abed289960cb3d6bda32  7772 pts/1    00:00:00 login
804c415fca9ed75a14e9e45c7e19e8712e45f9693fb8abed289960cb3d6bda32  7783 pts/1    00:00:00 bash

Shouldn't docker allocate a PTY/TTY when using the -t switch to the process within the container?

[creack]

Hmm, this is weird. I see the issue, however, docker does allocate a pty and perform a logintty on it. I'll investigate.

[creack]

Ok, thanks to @jpetazzo I understand. The shell is actually within a pty but the pty itself is outside the container, so commands like 'tty' thinks we are not within a tty.
However, if you directly call the isatty() function, it will return true.

The solution would be to create the pty within the container instead of outside.

In the meantime, in order to start tmux or screen, you can do as you did, use gettty, or simply start the script (or getty) command, or any other command that will create a new pty in top of the already existing one.

[jpetazzo]

For the record, it is possible to re-open stdin/stdout/stderr (with e.g.
"exec >/dev/tty 2>/dev/tty </dev/tty").
This makes screen behave semi-OK, but tmux is still confused.

[deibuji]

Thanks for the update guys. Look forward to the fix and thank you for the 'script' work around; I was looking for a command that created a pty.

[gasi]

Having a similar issue with setting up an SSH server on CentOS, see: https://gist.github.com/gasi/5691565

[rahulg]

I'd also like to report that this very issue prevents pacman (the ArchLinux package manager) from running properly within a docker container. pacman uses gpgme, which appears to fail because it attempts to use an ioctl on a pty it can't find, causing pacman to segfault.

The above workaround by jpetazzo works brilliantly, though. So for all the other folk attempting to run ArchLinux within a docker container, run the little command above when you run a new container.

[vreon]

Thanks @rahulg (and @jpetazzo), just ran into this myself.

[metalivedev]

I found this to be helpful in understanding the exec redirection above:
http://www.tldp.org/LDP/abs/html/io-redirection.html

• exec: replace this shell with another one, in the same process
• >/dev/tty: implicitly this is file descriptor "1", stdout. So in this new shell, redirect stdout to /dev/tty
• 2>/dev/tty: same thing for stderr, file descriptor 2
• </dev/tty: and if you get any input from /dev/tty, send that to stdin (the 0 is implied/default for input, 1 for output).

at least that's the way I'm reading it.

[sylvinus]

@jpetazzo your workaround gets screen to launch but I can't reattach to any screen. (is that what you meant by "semi-ok" ? ;-)

[jpetazzo]

I hadn't tested so far :-)

The long term solution is to create the pty inside the container.

[stucki]

Thanks for the hints, here is what I'm using now:

docker run -i -t ... sh -c "exec >/dev/tty 2>/dev/tty </dev/tty && /usr/bin/screen -s /bin/bash"

Works perfect!

[karellm]

@jpetazzo Do you know a solution to run tmux? Is it a limitation from Docker and if so are there plans to change it?

[creack]

@karellm You don't like the script or getty solution?

The limitation comes from Docker as the PTY is allocated outside the container. Yes, there are plans to change it but not in a near future. It will come with long running docker init.

[ghost]

When I use the script workaround the /dev/mapper partition fills up till the container crashes. I'm using an ArchLinux container. So the script workaround is not really a solution for me.

[creack]

Do you dump all the script output to disc? If you tell script to dump to /dev/null instead to typescript, it should be fine.
Anyhow, with #3580, we have the first step toward proper tty handling (i.e. within the container.) It should be there soon.

[ghost]

Think it's a bug. I dump all the output to typescript. But we're talking about GBs of ASCII text in an hour. Even I am not that productive. ;-) Good news an update is on the way. I will wait it out. Thanks for your quick response!

[unclejack]

Fixed by #4135.

[LordCope]

Currently using 0.8. I have a fedora container, and have the same issues with tmux / screen. However I can't run script either:

$ script
script: openpty failed: Operation not permitted

while this fix isn't in an installable package, any ideas on a workaround?

[crosbymichael]

@LordCope True, the fix for this will be in 0.8.1. The fedora image may need to be updated.

[LordCope]

Roger that. Suggested workaround meanwhile? sudo tmux seems to suck quite hard.

[crosbymichael]

@LordCope we are creating the release now.

see pr #4207

[dbabits]

What is the status of this? It's been 2 years.. tmux still doesn't run inside docker (not a tty) Docker version 1.3.3

[akerl]

@dbabits This issue definitely is resolved. You may want to double check your image

[dbabits]

@akerl , please see fresh issue #8755 where the same issue is discussed with exactly the same symptoms I experience. If this has been resolved, could somebody comment on what we are doing wrong.

thanks

[akerl]

That is a different issue relating to docker exec, which did not exist when this issue was opened.

[dbabits]

@akerl Ok, is this a bug or not?

[akerl]

#8755 is a bug which exists. #728 was a bug, but it's been fixed for a long time.

[dbabits]

@akerl Seems like the same bug replicated in a different place. Anyway, great that we cleared up the confusion. Thanks!

[travisghansen]

I've got the same issue going on but I'm not sure the best way to work around it. If anyone has a tip that would be great.

I'm launching apache via supervisor. I'm using the gnupg (pecl extension) for PHP which leverages gpgme similar to pacman mentioned above. Anytime code with the extension gets called the httpd process dies with signal 11.