docker start -i fails to attach to stdin

[WhisperingChaos]

Steps To Reproduce

• Create an image using the following Dockerfile source:

    FROM       ubuntu:12.04
    RUN echo "dlw_sshserver">/root/ComponentName.txt
    ENTRYPOINT  /bin/bash

The above essentially creates a bash command shell.

• Test 1
  • Execute image: 'docker run <imageGUID>.' Container 'X' is created and since STDIN wasn't left open with '-i' option, the bash process terminates and the container transitions to the stopped state.
  • Now start newly created container 'X' requesting interactive mode: 'docker start -i <XGUID>.' Container executes but fails to connect its STDIN to current terminal session and then transitions to the stopped state.
• Test 2
  • Execute image but this time enable interactive option: 'docker run -i <imageGUID>.' Container 'Y' is created and since STDIN is open with '-i' option, the current command terminal connects to the container's executing bash process. The container remains running and responsive.
  • Stop running the 'Y' container: 'docker stop <YGUID>.' The 'Y' container transitions to the stopped state.
  • Start running the 'Y' container requesting interactive mode: 'docker start -i <YGUID>.' Under these circumstances and in opposition to the behavior of 'Test 1', the start command connects the Y container's STDIN and the container remains running and responsive.

Environment

• Using docker version 1.3.1.
• Ubuntu 12.04.4 LTS

Behavior Assessment

Why the different behavior between the 'start' command of 'Test 1' vs the 'start' of 'Test 2'? After reviewing the image meta data for both 'X' and 'Y' containers using the docker inspect command, the differing behavior between the containers seems related to the Config.OpenStdin option. The boolean setting for this 'Y' container field is 'true', as established by the docker run command, while 'X's value is 'false'. This boolean setting not only advertises the capability of the container, but also determines its availability. Specifying the availability of a container option must be what's conveyed by the phrase "...final control to the operator who starts the container from the image." that appears in the docker run documentation.

Since run options of '-i' and '-a' are also accepted by start, unlike other options that are immutable, like the volumes option -v, it's not apparent that the availability of these options is controlled by the run command and that the '-a' and '-i' options of the start command can only affect the values of these options made accessible by run. There's nothing mentioned by reading the documentation of of start that alerts readers to this intentionally designed behavior. Besides augmenting the 'start' command's documentation, perhaps a more descriptive explanation of 'final control' could be incorporated into the run documentation.

[coolljt0725]

I think the AttachStdin option is the meta data of a container, it only can be changed by docker create and docker run is equal to docker create + docker start. Though docker start has the option -i -a, but it only work when the contain created with -i

[aanm]

I was able to replicate what @WhisperingChaos said but I think @coolljt0725 is right. The docker start has the option -i -a, but it only work when the contain created with -i.

[WhisperingChaos]

Thank you @coolljt0725 and @aanm for your review of this submitted issue!

I imagine my discussion in the "Behavior Assessment" section wasn't clear. I agree with both of you: the -i & -a options implemented by docker create & docker run control the option values assignable to the -i & -a options that can be specified by the docker start command. There's no dispute that this is the intended behavior. The issue is with the docker start documentation not the command itself.

I simply want the docker start documentation to convey the dependency between its option values and docker create and docker run because:

• Unlike other immutable options, such as -v for host volume binding that cannot be specified as an option for docker start, the -i & -a options do appear as options for this command. Since they can be specified, it suggests that all combinations of their values can be applied by docker start, as the restrictions imposed by docker create or docker run are omitted from docker start's definition.
• The following sentence appears in the docker create documentation: " Note that volumes set by create may be over-ridden by options set with start." Although the documentation states that the 'volumes' option '-v' can be changed by docker start, the 'volumes' option isn't defined for start. Also, I've attempted using -v option with Docker version 1.3.1 and it rejects this option. However, on the same page, there's an example immediately below this statement that illustrates docker start overriding the -i & -a options specified by a preceding docker create. Therefore, one could reasonably conclude from this bug in the documentation that -i & -a options specified by docker start can fully replace the ones specified by both docker run and docker create, as there's no stated restriction, expressed by the documentation, that limits the extent of 'over-ridden'.

To summarize:

• Augment the documentation for docker start to include notation explaining its dependence on docker create and docker run.
• Explain in greater detail what's meant by the statement: "..final control to the operator who starts the container from the image." that appears in the docker run documentation.
• Correct either the docker start definition to include the 'volume' option, if its now supported in versions after 1.3.1 or the reference by docker create which states that docker start supports this option.

[coolljt0725]

PR #10549 is going to add some docs for this.

[estesp]

Actually, I'm not sure there is any reason this can't be remedied. A hack to prefer command line over reading the inspect (container.Config) output makes it work properly with a quick test. Given all the right--in fact the same--setup happens for tty and stdin/stdout/stderr in run and start (because they are both using attach under the covers), I can't come up with a reason that this couldn't be resolved.

[GordonTheTurtle]

@WhisperingChaos It has been detected that this issue has not received any activity in over 1 year. Can you please let us know if it is still relevant:

• For a bug: do you still experience the issue with the latest version?
• For a feature request: was your request appropriately answered in a later version?

Thank you!