Control-C while running docker attach should not terminate the Docker container

[lhazlewood]

Per this Pull Request thread based on 0.6.5 to 0.6.7 functionality:

I believe most people feel that that if you run docker attach that Control-C should detach you and never shut down the container - in all cases. Stopping the container is what docker stop is for. It is important to have feature symmetry and not surprise people:

IMO, end-users shouldn't be surprised by default behavior. When you docker attach, it is a surprise that Ctrl-C kills the container, because you expect the attachment to discontinue (i.e. 'detach'), not stop the container entirely - since that is what docker stop is for.

(now, if an end-user wants to terminate the container from attachment with Control-C, maybe that is supported by adding an explicit argument to the docker run command. This just shouldn't be the default. However, I presume that this extra feature wouldn't be worth working on until people ask for it).

[lhazlewood]

cc @shykes

[jpetazzo]

OTOH, if I do docker attach and see that something is running and want to stop it, what should I do?

Maybe Ctrl-C should display something like "Hit ^C again to send it to the container. To detach, hit ^P ^Q." ... ?

[lhazlewood]

@jpetazzo This is simple (to me at least):

sudo docker attach <containerId>
Ctrl-C
sudo docker stop <containerId>

This is symmetric and without surprise: Ctrl-C detaches docker attach and docker stop terminates docker run.

[lhazlewood]

@jpetazzo

p.s. I think your suggestion is really nice, but this should not be the default. IMO, an argument to docker run should be specified to enable your suggested behavior.

[lhazlewood]

@shykes @jpetazzo any progress on this? I don't see a milestone associated with this, so I can't tell if you guys have it scheduled. Any ideas? Thanks!

[crosbymichael]

@lhazlewood To be consistent with every other docker command Ctrl+C terminates the process/container and Ctrl+P+Q detaches.

Incase you don't know, docker run == create, start, attach.

[creack]

The behavior you are looking for can be achieved with docker attach -sig-proxy=false ID.

On Thursday, December 19, 2013, Les Hazlewood wrote:

@shykes https://github.com/shykes @jpetazzohttps://github.com/jpetazzoany progress on this? I don't see a milestone associated with this, so I
can't tell if you guys have it scheduled. Any ideas? Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2855#issuecomment-30982423
.

Guillaume J. Charmes

[lhazlewood]

@crosbymichael I'm aware of how docker run works, but thanks for refreshing :)

If I attach to an already-running container, the intuitive expectation is that if I want to detach, I would use Control-C as this is the most intuitive, widely-used control for 'get me outta here'. The container shouldn't be stopped - because all I want to do is get out of being attached - and I shouldn't have to know special Docker control commands. It is an abrasive experience otherwise. Don't Surprise The User. :)

For command-line suite design (like git and docker), I think it is more important to have intuitive, context-relevant controls per sub-command. While control symmetry across all sub-commands in a suite is desirable, this is a secondary objective to what is most intuitive for the specific sub-command being executed. (For example, this book on building command-line application suites covers these concepts quite well).

@creack -sig-proxy=false is fine, but I'm stating that this should be the default when docker attach is used to connect to an already-running container. -sig-proxy=true can be the default when attaching during docker run for example, if that is most intutive.

Bottom line: the command line tool should not surprise the end-user. It is a surprise that the container is stopped when all you want to do is detach. No one would know to try Control+P+Q unless they read docker documentation first. I believe this is not desirable.

In any event, that's my .02. Thanks for all the great work you guys are doing on Docker - please keep it up!

[lhazlewood]

Follow up:

Running VirtualBox on a Mac, I cannot execute Control+P+Q to detach. Control-C works however (but again, with the undesired side effect of killing my container). The only option is to specify sig-proxy=false any time I want to attach to an already-running container. :/

I'd love to see this fixed! :)

[shykes]

Les you make a good point. I'm the one to blame for the "carpet-bomb consistency" across run, start and attach. My reasoning was that the default behavior should be consistent. But in the case of attach I see the problem.

Ironically now I worry about causing even more damage by "flip-flopping" and changing back the attach behavior. What do you think?

On Thu, Dec 19, 2013 at 6:15 PM, Les Hazlewood [email protected]
wrote:

Follow up:
Running VirtualBox on a Mac, I cannot execute Control+P+Q to detach. Control-C works however (but again, with the undesired side effect of killing my container). The only option is to specify sig-proxy=false any time I want to attach to an already-running container. :/

I'd love to see this fixed! :)

Reply to this email directly or view it on GitHub:
#2855 (comment)

[lhazlewood]

@shykes No blame necessary! That's why the community is so awesome - so feedback like this hopefully makes things better for everyone.

As for 'flip-flopping', I don't think that will be a problem. The latest docs still reflect that Control-C detaches from an already-running container, so not many people probably know about this yet. And it's only been in effect for two point releases (0.6.6 and 0.6.7), so it probably didn't affect many people. If you can get this out in 0.7, that'd be ideal, and then most would be 'none the wiser'. Finally, because Docker is not yet at 1.0, I see this as much less harmful, especially with the (hopefully minimal) impact.

Plus, as a nice bonus, you wouldn't have to change the existing docs :)

Again, you guys rock - keep up the great work. Docker is coming along beautifully!

[SvenDowideit]

in trying to answer https://groups.google.com/forum/#!topic/docker-user/BEdffdKBE9w

I was just testing 0.9.0, and got the following

I was expecting that I could use --sig-proxy the same way in run (to essentially allow me to choose to make a daemonised container from run (or type exit)

but it looks like --sig-proxy is not consistent between run and attach.

can someone please help me work out how to document it

$ docker run -d ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
77ce5ec9522ecfdbda29bbc7ab2a64b8c117c9bf33d41078112918cd8588e6ea
$ docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                   NAMES
77ce5ec9522e        ubuntu:12.04        /bin/sh -c while tru   6 seconds ago       Up 5 seconds                                hopeful_wozniak
d0f7b486ff9c        eg_sshd:latest      /bin/sh -c /usr/sbin   2 days ago          Up 2 hours          0.0.0.0:49153->22/tcp   test_sshd
$ docker attach --sig-proxy=false hopeful_wozniak
hello world

hello world
hello world
^C
$ docker stop hopeful_wozniak
hopeful_wozniak
$ docker run -it --sig-proxy=false ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
hello world
hello world
hello world
^C
$ docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                   NAMES
d0f7b486ff9c        eg_sshd:latest      /bin/sh -c /usr/sbin   2 days ago          Up 2 hours          0.0.0.0:49153->22/tcp   test_sshd

[alco]

Sorry if I'm crashing a wrong discussion. I just found that docker attach and docker logs --follow have different behaviour regarding the use of ^C, although the docs for that latter say

The docker logs --follow command combines docker logs and docker attach

I start a long running process with -i and -t options. Pressing ^C in this case terminates the container.

I can use the ^P^Q shortcut to detach from the container. If I then docker attach to it, the behaviour is the same.

But when using docker logs --follow, ^P and ^Q seem to be passed through to the container and ^C only detaches docker from it.

I think either the docs are misleading on this point or it doesn't work as expected.

[tachang]

I just ran docker attach and tried to control+c and I couldn't get out.
I opened up another shell window and tried to do kill of the docker attach and still couldn't get it to quit.

I'm fairly new to docker but my expectation was for it to detach or at least stop what I did.

[c4milo]

Shouldn't this issue be closed? I'm using docker 0.11.1 and when running containers with -t, I'm able to detach using Ctrl+C without the container being stopped.

[jpetazzo]

On 0.11.1:

$ docker run -t -i busybox sh -c "while sleep 1; do echo hello ; done"
hello
hello
hello
^P^Q
$ docker attach $(docker ps -q -l)
hello
hello
^C
docker ps -l
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                       PORTS
d5b115fa9c86        busybox:latest      sh -c 'while sleep 1   16 seconds ago      Exited (130) 2 seconds ago

I don't have a strong opinion on what should be the "right" behavior.

I still think that some people will expect ^C to detach, others will expect ^C to terminate the container.

Parallel: look at screen or tmux. When attaching to a session, ^C sends ^C inside the session; it doesn't detach.

[romansky]

The current behavior is weird, why would anyone one want it as it works right now where you can not exit an attach without killing the terminal from another session?

[lhazlewood]

I'm surprised this issue is still open. Ctrl-C should detach. Use docker stop (which is already self documenting) if you actually want to stop the container. This is simple, easy to understand, and does not surprise the user. @shykes also confirmed above that the current behavior is not as intuitive as this suggested approach.

Any updates from the Docker team to getting this fixed?

[dmr]

I found this discussion via google after I got "stuck" in docker attach. Thanks for suggestion some solutions, IMO Ctrl+C should detach, there is docker stop if I want to stop the container

[lhazlewood]

Hi guys! Any update on this? This continues to be a frustration point (and by the looks of it, plenty of others). Thanks!

[dsoprea]

I'm waiting on this, too.

[nathanleclaire]

^C is a quite universal UNIX idiom for "send SIGTERM to the process which is currently running in the foreground" (usually stopping it). If doing ^C when attached a container detached from the container instead of terminating the process, this would leave the process running, which is inconsistent with the aforementioned ^C shell idiom.

Detaching is more analogous to ^Z than it is to ^C. The ^P^Q sequence is a little unwieldy at first to learn but Googling "docker detach" yields this advice on StackOverflow right away, so it's not too hard to find out about and get used to. Additionally, I can't think of a situation where accidentally killing a process you are attached to with ^C would be a Very Bad Thing, since if you just want to see the output you have docker logs (without the risk of killing the container) and spinning up a new container of the same kind is very fast and cheap.

edit: I guess I should clarify that I mean, I can't think of any scenario where you should be attached to a container, where accidentally ^C-ing the process would be bad. In production is not the place for attaching, detaching, fiddling, tinkering, etc.

[lhazlewood]

@nathanleclaire I believe you're debating an implementation detail and not addressing what people actually want. The reality is that people consider the 'attach' behavior as a separate process from the underlying docker container. It may not be, but that's just an implementation detail. This means that if I attach, I want the attach process to cancel - not the underlying docker process.

"I can't think of a situation where accidentally killing a process you are attached to with ^C would be a Very Bad Thing"

Um. Try telling that to anyone that runs docker in production. :)

It is very easy for a sys admin to ^c after attaching because it's just ingrained in their muscle memory as they move about the terminal. They don't even think about it.

[nathanleclaire]

"I can't think of a situation where accidentally killing a process you are attached to with ^C would be a Very Bad Thing"

Um. Try telling that to anyone that runs docker in production. :)

It is very easy for a sys admin to ^c after attaching because it's just ingrained in their muscle memory as they move about the terminal. They don't even think about it.

Why would you be attaching to containers for this purpose? Just curious. And have you considered nsenter, which actually would spawn a new process as you desire? https://github.com/jpetazzo/nsenter

[jasonblanchard]

+1 to @lhazlewood. That was exactly my thinking and my confusion about this behavior.

[thaJeztah]

+1 to @lhazlewood but I concur that nsenter is a nice choice for many (not all) tasks.

Making ^C detach just seems like a safer option. For those situations that I want to stop a container, I just run docker stop, which is much clearer on its intent than inadvertently killing a container via ^c.

After all, I don't think anyone would like to have their production server shutdown when they ^c during a ssh session (just for the analogy)

[erikh]

Scenario:

docker attach `docker run -itd busybox sleep 100000000`
hit ctrl+C

If you did not have this option, the container would not terminate. ^P^Q terminates the attach today, if you just want to do that.

On Aug 8, 2014, at 1:54 PM, Sebastiaan van Stijn [email protected] wrote:

+1 to @lhazlewood https://github.com/lhazlewood but I concur that nsenter is a nice choice for many (not all) tasks.

Making ^C detach just seems like a safer option. For those situations that I want to stop a container, I just run docker stop, which is much clearer on its intent than inadvertently killing a container via ^c.

After all, I don't think anyone would like to have their production server to shutdown when they ^c during a ssh session (just for the analogy)

—
Reply to this email directly or view it on GitHub #2855 (comment).

[jessfraz]

now that we have docker exec is this still an issue?

[jtmarmon]

yes it is @jfrazelle. If I want to see active server logs I'll use docker attach to view the running process. exec won't do that for me

[cpuguy83]

@jtmarmon That's what docker logs is for.

[tianon]

but that's what "docker logs -f" is for :)

[jtmarmon]

haha okay you got me, but my point still stands. there are other use cases for attaching to a running process. seems a bit odd to be able to kill a container process with absolutely no warning imo.

also man you guys are fast

[jessfraz]

I feel like we need to decide is this intentional or not (I am heavily leaning towards desired behavior) and document as so, so that people know.

[thaJeztah]

Documentation has been already been corrected. Although this is by design, #2855 (comment) nicely summarises my thoughts. Perhaps a similar approach as nodeJS would accommodate both "camps"?

(press ^C again to quit or ^P ^Q to detach)

(my final suggestion on this. I'm too opinionated on this, think it's up to the maintainers to vote/make a decision)

[spullara]

This was extremely surprising to me.

[izdi]

Also docker run and cancelling (ctrl+c) the process won't kill, it instead it causes next operation to wait previous process to finish download image.

[jplandrain]

+1 to @lhazlewood ^C should detach

[pbutlerm]

+1 to @lhazlewood ^C should detach

[iwkse]

+1 to @lhazlewood ^C should detach

[thaJeztah]

There's currently a PR to make the key-combination configurable; #15666

[thaJeztah]

Removing the "needs attention" label, there's now a PR

[thasmo]

I've been surprised too, that ctrl+c killed the container/process instead of detaching.

[sebastianvilla]

+1 to @lhazlewood ^C should detach

[cpuguy83]

Well, good news, you can now do --detach-keys ctrl-c for this behavior, which can also be set in a config file under ~/.docker

Closing as the current behavior is the "correct" behavior and is in line with the how SSH handles detaching (albeit different key sequence), and also the detach sequence can be changed to use ctrl-c (or any other combination) people want.
This functionality will be in Docker 1.10, currently slated for early February.

[thaJeztah]

For more info on the "configurable detach keys", see the pull request: #15666

[antoine-lizee]

+1 for ^C should detach by default. attach is definitely different from run, and I end up using exec ... bash in part just because of this. I got so surprised when I killed my dokku the first time after doing some maintenance!

[cpuguy83]

@antoine-lizee: this is not going to change. You can set this value yourself both per command with a flag as well as a default via config file.

[ghost]

+1 to @lhazlewood ^C should detach

I am logged into a into a live container to check what's going on in there. Intuitive reaction ^C to leave.

[rodionos]

+1 to @lhazlewood ^C should detach

[thaJeztah]

I'm locking this issue; the default key-combination is not going to change, and you can now set your own default using a configuration file #15666. I understand that for some people ^C is the preferred combination and they are now able to do so.