Why the 'i' option of the docker start command does possible display a command's output?

[manueljordan]

About Docker if is executed the following command

docker run --name ubuntu-it -it ubuntu

The container named ubuntu-it, based on the ubuntu image, is created, run, is offered a tty and finally remains running. It can be stopped with the exit command. Here the importance about the it option to let have a shell available for human interaction.

For experimental purposes, if is executed the following command

docker run --name ubuntu-a ubuntu ls

The container named ubuntu-a, based on the ubuntu image, is created, run, is listed/displayed the execution of the ls command and finally the container is stopped.

If is need it re-run the ubuntu-a container is mandatory use the docker start command.

If is executed:

docker start ubuntu-a

Nothing is shown in the tty. According with the official documentation for the docker start command about its options it indicates:

-a, --attach Attach STDOUT/STDERR and forward signals

-i, --interactive Attach container’s STDIN

Therefore if is executed:

docker start -a ubuntu-a

Is possible run again the container and the output of the ls command is listed/displayed, it because the current tty is attached with the STDOUT/STDERR stream(s) of the container. Until all is clear.

The reason of this post. If is executed (observe now is the i option):

docker start -i ubuntu-a

Is possible run again the container and the output of the ls command is listed/displayed too. Why happens this if the i option is based on the STDIN stream?

[rimelek (Ákos Takács)]

Since it is related to your other question and I wrote about TTY and standard input as well, and linked anothe rpost which was about attaching to the standard streams, I just link the other topic here too

Trying to understand the relation of tty between the host and container when the docker run command is executed

My old reply in another topic could be useful here: In your case, the TTY is not for having an output. Some programs like a shell need a pseudo TTY to be able to run. You run the following command: docker run -d --name bash-1 bash It will run and stop immediately. Now run this: docker run -d --name bash-2 -t bash It will keep running. Or just try to run it in interactive mode: docker run --rm -i bash You can type characters, but there is nothing to handle what you typed without the TTY. …

But again the interactivity has nothing to do with the output. Commands will run, you will just not be able to work interactively.

@manueljordan

Why happens this if the i option is based on the STDIN stream?

You didn’t do anything with the standard input, did you?

[manueljordan]

Thanks for the reply

Pls, read my first answer of the other post about your first answer, before to continue here

But again the interactivity has nothing to do with the output. Commands will run, you will just not be able to work interactively.

Agree, the commands will run, but within the running container, it through its own internal tty. Therefore if the docker start command is executed with the a option then through the host’s tty is possible see the data displayed of the command executed within the container. Otherwise is not possible and is clear here the importance to use the a option.

you will just not be able to work interactively.

Agree, if the command was executed with neither the a nor i options. Therefore there are not neither the STDOUT/STDERR nor STDIN streams respectively

You didn’t do anything with the standard input, did you?

No, I didn’t. But with the i option I expected see nothing because the I/O Streams are different, STDIN vs STDOUT.

Thanks for your understanding

[rimelek (Ákos Takács)]

@manueljordan

Therefore if the docker start command is executed with the a option then through the host’s tty

Assó I wrote about it in the other topic, `-a^ attaches to the standard streams, not a TTY… The difference between docker run and docker start is that docker start does not attach to the standard streams by default, but docker run does. Interactivity and TTY are not related to the standard output.

[manueljordan]

Again thanks for the polite reply

Assó I wrote about it in the other topic, `-a^ attaches to the standard streams, not a TTY…

Agree until some point, a attaches only the STDOUT and STDERR streams

-a, --attach Attach STDOUT/STDERR and forward signals

Nothing about STDIN, thus the importante of the i option

-i, --interactive Attach container’s STDIN

Therefore having:

• docker run --name ubuntu-a ubuntu ls
• docker start -i ubuntu-a

(A) Why the docker start command with the i option displays in the host tty the STDOUT content of the started container about the ls command data output?

The difference between docker run and docker start

Yes, I did do realize the difference between the it and ai options for each command respectively

is that docker start does not attach to the standard streams by default

Agree and confirmed through the use of the a and i options but is not clear the (A) scenario. Reason of this post

, but docker run does

Is it explicitly documentated at docker run? It seems not. If not, how did you know that?

Thanks for your understanding.

[rimelek (Ákos Takács)]

@manueljordan

Nothing about STDIN, thus the importante of the i option

I’m not entirely sure why attach doesn’t support stdin here, I have to admit. I guess it could be related to that docker start just starts an existing container and you can use -a to see the output of the process runing inside. You don’t need stdin there and this -a option is just a flag, so you can’t decide which streams you want to attach to. And docker run attaches to stdout and stderr as well by default.

You can use docker start -i if you want to send something to the standard input, but I never needed that and I don’t have ideas for a use case.

@manueljordan

(A) Why the docker start command with the i option displays in the host tty the STDOUT content of the started container about the ls command data output?

That is actually a good question. It seems like a bug, but it worked this way in Docker 20.10 too (I tried it now).

@manueljordan

Is it explicitly documentated at docker run? It seems not. If not, how did you know that?

Probably the same way as you The documentation could include more details, but it is pretty easy to realize you are not attached to the standard streams when you run the docker start command and you get the prompt back without any output. Except, as you pointed out, somehow -i shows the output. I have no answer to that.

Maybe there is some kind of logic, but I don’t see that either.