Confused about Docker -t option to Allocate a pseudo-TTY

Question

What exactly does this option do? I've been reading a lot on TTY and I'm still confused. I played around without having the -t and just -i and it seems like programs that expect user input throw an error without the -t. Why is it important for pseudo-TTY to be enabled?

Answer 1

There is a mention in the Docker online documentation which says it is to "Allocate a pseudo-tty" and is often used with -i:

https://docs.docker.com/reference/run/

I saw it used in the documentation for the terrific jwilder/nginx-proxy docker container in the following way:

docker run -d -p 80:80 --name nginx -v /tmp/nginx:/etc/nginx/conf.d -t nginx

In this case, what it does is send the output to the 'virtual' tty (Bash command prompt/terminal) within this docker container. You can then see this output by running the docker command docker logs CONTAINER where CONTAINER is the first couple of characters of this container's ID. This CONTAINER ID can be found by typing docker ps -a

I've seen this -t argument mentioned briefly in the following link, where it says

The -t and -i flags allocate a pseudo-tty and keep stdin open even if not attached. This will allow you to use the container like a traditional VM as long as the bash prompt is running.

https://coreos.com/os/docs/latest/getting-started-with-docker.html

Answer 2

The -it combined options are known as interactive mode.

By default, containers only have an stdout stream (i.e., docker run | CMD works), to interact with our container, we need these two options:

• -i adds an stdin stream (i.e., CMD | docker run works);
• -t allocates a pseudo-TTY master/slave pair with the slave part tied to the running process in the container and the master part tied to your docker command.

The stdin stream attaches the container to the stdin of your shell (docker inherits the stdin stream of your shell) while the TTY line discipline gives you the ability to interact with the container in a keyboard fashion.

The TTY line discipline consists of low-level features provided by the kernel to TTY devices, such as an editing buffer and basic line edition commands.

As shown below, you can check the standard file descriptors with the following command:

docker run --rm -i ubuntu sh -c "ls -l /proc/\$\$/fd"

If you remove the -i you'll see that stdin points to /dev/null (i.e., no stream is allocated).

Answer 3

Most of the answers here are great conceptual answers, but I found that they left out too many details for me to be able to use the information while sitting at the computer. Ahmed Gnomin's answer is on its way to being programmatic, but let's try to push it one step further.

First a bit of theory

Two images in The TTY Demystified are key:

I can't claim to fully understand this picture, but the relationship of interest here is that when xterm (or gnome-terminal in ubuntu; represented by one of the "user process" bubbles in the above image) opens up, it starts a bash (or whichever default shell), and then sends keyboard inputs to it via the kernel pseudo-terminal (PTY) master and slave:

xterm -> ptmx (pty master) -> pts (pty slave) -> bash

The second image represents the processes' involved in this short bash session:

>>> cat
>>> ls | sort
...

The key bits of information are the TTY and stdin, stdout, stderr lines. This shows that each process is associated to a TTY (teletype terminal), and that their 3 streams (stdin, stdout, stderr) are quite naturally associated to this TTY, except in the case of pipes or redirections (notice that the pipe ls | sort associates ls' stdout to sort's stdin).

Now a bit of testing out the theory

We can find the pseudo-terminal used by bash by typing tty:

>>> tty
/dev/pts/2

Bash is thus associated to the PTY slave number 2 (this probably means that there is another terminal open, associated to the master/slave pair 1). We can also get bash's stdin, stdout, and stderr streams:

>>> ls -l /proc/$$/fd
lrwx------ 1 samlaf samlaf 64 Jun 17 21:50 0 -> /dev/pts/2
lrwx------ 1 samlaf samlaf 64 Jun 17 21:50 1 -> /dev/pts/2
lrwx------ 1 samlaf samlaf 64 Jun 17 21:50 2 -> /dev/pts/2

Indeed, they are all associated with bash's natural TTY slave. ($$ is a bash variable which returns bash's PID. We can equally find it by using ps and typing it by hand).

And finally using this theory to answer the initial Docker question

We reproduce the above steps, but this time inside a docker container:

>>> docker run --rm -t ubuntu tty
/dev/pts/0
>>> docker run --rm ubuntu tty
not a tty

which makes sense since -t allocates a pseudo-terminal.

The -i related commands are harder to interpret.

>>> docker run --rm ubuntu bash -c "ls -l /proc/\$\$/fd"
lrwx------ 1 root root 64 Jun 18 02:37 0 -> /dev/null
l-wx------ 1 root root 64 Jun 18 02:37 1 -> pipe:[9173789]
l-wx------ 1 root root 64 Jun 18 02:37 2 -> pipe:[9173790]
>>> docker run --rm -t ubuntu bash -c "ls -l /proc/\$\$/fd"
lrwx------ 1 root root 64 Jun 18 02:39 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jun 18 02:39 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jun 18 02:39 2 -> /dev/pts/0
>>> docker run --rm -it ubuntu bash -c "ls -l /proc/\$\$/fd"
lrwx------ 1 root root 64 Jun 18 02:39 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jun 18 02:39 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jun 18 02:39 2 -> /dev/pts/0

I still can't figure out what exactly -i does... I would love some help! The only interesting command I could find in which it seems to make a distinction is:

>>> docker run --rm -a stdout -i ubuntu bash -c "ls -l /proc/\$\$/fd"
lr-x------ 1 root root 64 Jun 18 02:43 0 -> pipe:[9199896]
l-wx------ 1 root root 64 Jun 18 02:43 1 -> pipe:[9199897]
l-wx------ 1 root root 64 Jun 18 02:43 2 -> pipe:[9199898]
>>> docker run --rm -a stdout ubuntu bash -c "ls -l /proc/\$\$/fd"
lrwx------ 1 root root 64 Jun 18 02:43 0 -> /dev/null
l-wx------ 1 root root 64 Jun 18 02:43 1 -> pipe:[9197938]
l-wx------ 1 root root 64 Jun 18 02:43 2 -> pipe:[9197939]

The Docker documentation mentions that -a "attaches to the stream passed as input", but I haven't been able to find an explanation for what this means, and how its related to the -i options.

Answer 4

Every process has three data streams i.e STDIN/ STDOUT/ STDERR. When a process is running in a container, by default terminal is connected with STDOUT stream of the process running in the container. Hence all the output streams will be visible while running docker run command in the terminal. But if you want to provide input to the running process in the container then you have to connect with STDIN channel of the process which is not by default and is done with docker run -i command.

-t is used for interactive/ formatted input operations.

Answer 5

Late answer, but might help someone

docker run/exec -i will connect the STDIN of the command inside the container to the STDIN of the docker run/exec itself.

So

• docker run -i alpine cat gives you an empty line waiting for input. Type "hello" you get an echo "hello". The container will not exit until you send CTRL+D because the main process cat is waiting for input from the infinite stream that is the terminal input of the docker run.
• On the other hand echo "hello" | docker run -i alpine cat will print "hello" and exit immediately because cat notices that the input stream has ended and terminates itself.

If you try docker ps after you exit either of the above, you will not find any running containers. In both cases, cat itself has terminated, thus docker has terminated the container.

Now for "-t", this tells the main process inside docker that its input is a terminal device.

So

• docker run -t alpine cat will give you an empty line, but if you try to type "hello", you will not get any echo. This is because while cat is connected to a terminal input, this input is not connected to your input. The "hello" that you typed did not reach the input of cat. cat is waiting for input that never arrives.
• echo "hello" | docker run -t alpine cat will also give you an empty line and will not exit the container on CTRL-D but you will not get an echo "hello" because you didn't pass -i

If you send CTRL+C, you get your shell back, but if you try docker ps now, you see the cat container still running. This is because cat is still waiting on an input stream that was never closed. I have not found any useful use for the -t alone without being combined with -i.

Now, for -it together. This tells cat that its input is a terminal and in the same time connect this terminal to the input of docker run which is a terminal. docker run/exec will make sure that its own input is in fact a tty before passing it to cat. This is why you will get a input device is not a TTY if you try echo "hello" | docker run -it alpine cat because in this case, the input of docker run itself is the pipe from the previous echo and not the terminal where docker run is executed

Finally, why would you need to pass -t if -i will do the trick of connecting your input to cat's input? This is because commands treat the input differently if it's a terminal. This is also best illustrated by example

• docker run -e MYSQL_ROOT_PASSWORD=123 -i mariadb mysql -u root -p will give you a password prompt. If you type the password, the characters are printed visibly.
• docker run -i alpine sh will give you an empty line. If you type a command like ls you get an output, but you will not get a prompt or colored output.

In the last two cases, you get this behavior because mysql as well as shell were not treating the input as a tty and thus did not use tty specific behavior like masking the input or coloring the output.

Answer 6

The -it instructs Docker to allocate a pseudo-TTY connected to the container’s stdin, creating an interactive bash shell in the container.

--interactive, -i false Keep STDIN open even if not attached

--tty, -t false Allocate a pseudo-TTY

https://docs.docker.com/engine/reference/commandline/run/

Answer 7

The -t option goes to how Unix/Linux handles terminal access. In the past, a terminal was a hardline connection, later a modem based connection. These had physical device drivers (they were real pieces of equipment). Once generalized networks came into use, a pseudo-terminal driver was developed. This is because it creates a separation between understanding what terminal capabilities can be used without the need to write it into your program directly (read man pages on stty, curses).

So, with that as background, run a container with no options and by default you have a stdout stream (so docker run | <cmd> works); run with -i, and you get stdin stream added (so <cmd> | docker run -i works); use -t, usually in the combination -it and you have a terminal driver added, which if you are interacting with the process is likely what you want. It basically makes the container start look like a terminal connection session.

Answer 8

In linux when you run a command, you need a terminal (tty) to execute it.

So when you want to connect to docker (or run command in docker container), you have to provide the option -t which takes in the consideration of terminal inside the docker container.

Answer 9

What I know about the -t is the following:

docker exec -ti CONTAINER bash - allows me to "login" in the container. It feels like ssh-ing (it's not).

But the trouble was when I wanted to restore a database.

Usually I dodocker exec -ti mysql.5.7 mysql - Here I execute the mysql command in the container and get an interactive terminal.

I added <dump.sql to the previous command so I can restore a db. But it failed with cannot enable tty mode on non tty input.

Removing the -t helped. Still don't understand why:

docker exec -i mysql.5.7 mysql < dump.sql

The last one works. Hope this helps people.