moby: Cannot kill or detach a docker container using Ctrl-C or Ctrl-\

Starting with docker 0.6.5, you can add -t to the docker run command, which will attach a pseudo-TTY. Then you can type Control-C to detach from the container without terminating it.

If you use -t and -i then Control-C will terminate the container. When using -i with -t then you have to use Control-P Control-Q to detach without terminating.

Test 1:

$ ID=$(sudo docker run -t -d ubuntu /usr/bin/top -b)
$ sudo docker attach $ID
Control-C
$ sudo docker ps

The container is still listed.

Test 2:

$ ID=$(sudo docker run -t -i -d ubuntu /usr/bin/top -b)
$ sudo docker attach $ID
Control-C
$ sudo docker ps

the container is not there (it has been terminated). If you type Control-P Control-Q instead of Control-C in the 2nd example, the container would still be running.

A pull request to fix the docs for the Hello World daemon sample is here:

https://github.com/dotcloud/docker/pull/2845

I’m unaware of where you saw the recommendation to Control-C outside of this example. If you saw this reference somewhere else, can you please submit a new pull request to fix the docs you referenced?

You might also find this mailing list thread helpful.

From what I can gather you need both -t and -i for Ctrl-C to work as expected…

@felipekm Try adding --init when starting your container. This will start Tini as PID 1, and Tini will ensure your application gets SIGINT (instead of being intercepted by /bin/sh).

More details in the thread above.

Why was this closed? Can you please explain the reason?

I asked because it is obvious that the majority of the community does not want the current default behavior.

Also note that ctrl+pq does not work on Mac OS X running Ubuntu in VirtualBox.

1 year later we still can’t Ctrl+C a docker container

To have ctrl+c stop the container you must use -it To detach from the container you should use ctrl+pq

Closing.

Still don’t get it. Why Ctrl-C doesn’t send SIGINT?

I am VERY confused by all this.

The default behaviour when being in a shell prompt is that ^C kills the running foreground process. And if no such process exists, it just do nothing, except maybe show a new prompt. ^D on the other hand do exit the shell, without stopping the machine. This is what I expect, because this is what everyone else do.

So, why do Docker do it differently? And why do I read this strange discussion? Am I missing something?

@sebdelvalle You can. It’s just that not all docker containers respond to Ctrl+C. If you created software running in a docker container it’s your responsibility to handle Ctrl+C properly. If you don’t shutdown your software on Ctrl+C nobody will do it for you.

You see, when you run your software without docker you have a terminal and init system which does handle Ctrl+C. When you run it in docker, you don’t have any terminals. Your software becomes the system’s entrypoint. It’s like booting your software straight from reboot.

Finally you won’t have to modify images just to add tini so that your containers aren’t killed (exit code 137) when not responding to SIGTERM. Especially useful for databases to prevent data loss.

Just adding this as additional information (some of which is mentioned in earlier comments);

While using --init (or adding tini in your image) can be a quick way to help with images that don’t handle signals properly, be sure you’re not “masking” an actual problem with the image.

Tini provides the following features;

1. reaping of processes; any (Linux) process that spawns child processes is also responsible for reaping those processes once the parent process is terminated. This means that tini should not be needed, unless the container’s main binary violates this rule (unfortunately, there’s some examples out there).
2. it is started as PID-1, which means that the container’s main process now becomes PID-2. PID-1 is “special”; killing PID-1 means killing the “machine” (or in context of Docker; killing the container). Some processes therefore behave different if they are executed as PID-1; they will ignore (some) signals, to prevent being killed (as that would kill the machine, which is usually not desirable, unless you want to shutdown or reboot).

If you know that the process running inside the container is a “bad actor”, and doesn’t handle reaping, using --init is definitely a good choice to get you going. Be aware though, that you’re effectively running into a bug; be sure to report the issue with the maintainer/publisher of the software you’re running in the container: perhaps they’re not aware of this situation, and can fix it.

If you’re using --init because of 2., this may be because the image you’re running was not well-designed; Is the container’s main process actually the main process, or is it running in a shell?

For example; the following CMD will start a shell (/bin/sh or /bin/bash, depending on the image) in which mysqld is started;

CMD /usr/sbin/mysqld

Because of this, /bin/sh (not mysqld) has become the container’s main process (PID-1), and any signal sent to the container will be handled by /bin/sh (and not forwarded to mysqld). Using --init will “resolve” that situation (/bin/sh now runs as PID-2, and mysqld runs as PID-3), but still runs an unnescessary shell process in the container.

To make the container’s process run without a shell, use the JSON (“exec” form). For example, below is the CMD for the official mysql image;

CMD ["mysqld"]

But what if you need to run some commands when starting the container (before running the container’s main process), such as setting permissions, or doing some setup the first time the container is run?

These steps can be done in an entrypoint-script. The entrypoint script can run a shell, perform initialization (see for example the init steps in the official WordPress entrypoint script), and at the end switch to the container’s main process using exec.

When using exec, the current process is replaced with another process, so when using exec at the end of the entrypoint script, the container’s main process will run as PID-1, and not be running inside a shell; here’s the last line of the WordPress entrypoint script;

exec "$@"

The Dockerfile uses both an ENTRYPOINT and CMD, in which case CMD is used as parameter for the ENTRYPOINT;

ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["apache2-foreground"]

exec "$@" will thus default to exec apache2-foreground, but will be replaced with the command that’s used to start the container (for example docker run mysql echo "hello", will run the entrypoint script, then exec echo "hello")

TL;DR; the --init option is safe to use, and may help your situation, but be sure you’re not tapering over the actual problem in the image 😄

@johshoff It depends on how ping was started by the image. Is it running inside a /bin/sh? If so, the signal is sent to /bin/sh, which ignores signals when run as pid 1.

You can tell node.js to handle the signals:

// For Docker
process.on('SIGINT', function() { console.log('Caught Ctrl+C...'); process.exit(); }); // Ctrl+C
process.on('SIGTERM', function() { console.log('Caught kill...'); process.exit(); }); // docker stop

If you don’t need sh, don’t run it; using exec saves you from one extra process running inside the container, which may be helpful.

(Also, using docker run --init will automatically inject tini in your container, without the need to add it)

I had the same issue with my node.js apps… I fixed it with

/**
 * Does what it says :-)
 */
function endProcess(reason) {
        // eslint-disable-next-line no-console
        console.log(`Quitting... Reason: ${reason}`);
        process.exit();
}

/**
 * Adds hooks for Docker CTRL-C and Stop
 */
function dockerConfig() {
        [
                'SIGINT',
                'SIGTERM'
        ].forEach((signal) => {
                process.on(signal, () => {
                        endProcess(signal);
                });
        });
}

module.exports = dockerConfig;

1 year later we still can’t Ctrl+C a docker container

Now it’s 2 years 🎂 Still getting the error on MacOSX.

I’m still confused about this. Example run:

docker run -i $IMAGE
ping google.com
PING google.com (216.58.217.46) 56(84) bytes of data.
64 bytes from 216.58.217.46: icmp_seq=1 ttl=61 time=31.5 ms
^C64 bytes from 216.58.217.46: icmp_seq=1 ttl=61 time=31.5 ms
^C^C^C^C^C^C^C^C64 bytes from 216.58.217.46: icmp_seq=1 ttl=61 time=31.5 ms

So ctrl+c doesn’t send SIGINT to either the docker process or the ping process. Is docker stop my only option here? (ctrl+p, ctrl+c does also not work. I’m on OSX)

1. use docker run -it --init which will solve all your problems.

This fixed my issue with ctrl-c not working, AND restored the output coloring in my terminal (present when running server outside docker).

Thanks @FossPrime !

Can’t detach with CTRL+P,CTRL+Q in my Ubuntu 17.04 OS. Arrrghh

It’s possible to enable the init option as a default (by setting a daemon option); then all container, including those started as part of a service get --init. There’s a PR in progress https://github.com/docker/cli/pull/479

Quoting my recommendation above:

RUN apk add tini
ENTRYPOINT ["/sbin/tini", "--"]

Now you don’t care whether you use sh or you not in CMD.

Another way if you’re using node like @alvarow you can use npm start and a rule in package.json and npm will shut down on ctrl-c:

Like this:

{
  "name": "prom-koa-example",
  "version": "1.0.0",
  "description": "Expose prometheus metrics in koa",
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
  },
  "dependencies": {
    "koa": "^1.2.0",
    "koa-router": "^5.4.0",
    "prom-client": "^9.1.1"
  }
}

Put this to your alpine 3.4 Dockerfile:

RUN apk add tini
ENTRYPOINT ["/sbin/tini", "--"]

And you’re good to go.

So there’s shell form and exec form. Shell form is used like this:

CMD nginx

Exec form like this:

CMD ["nginx"]

In first case the shell handles your signal, in the second case the nginx process

In summary:

1. docker run -it won’t be enough if the program you run doesn’t handle it. specially problematic if it’s not your program… such as is the case when another program interprets your program in a limited way.
2. you can make ENTRYPOINT ["/sbin/tini", "--"] the entry point… instead of your app.
3. use docker run -it --init which will solve all your problems.

@guiambros that is so useful it’s going in my aliases.

@felipekm in another terminal type docker ps and then docker stop <container_id>

If you want Ctrl+C to work you’ll need to change your docker container to respond to SIGINT.

Here is my understanding of it.

When writing a Dockerfile, there are two commands relating to starting the container process: ENTRYPOINT and CMD.

ENTRYPOINT defines the executable to be launched, and CMD defines the arguments to be passed to the executable. By default, ENTRYPOINT is equal to /bin/sh.

Therefore, when a Dockerfile doesn’t have a ENTRYPOINT and only has a CMD "node src/index.js", the process that is actually running in the container is something like: /bin/sh -c "node src/index.js"

Now for some reason I do not fully understand, when sh receives a SIGINT, whether it is through a docker stop or ctrl-c in docker run -it ..., it does not forward this signal to the process it started (node src/index.js in that case).

So the correct way of defining a Dockerfile to run a nodejs container would be:

FROM node:8

# some stuff...

ENTRYPOINT ["node"]
CMD ["src/index.js"]

Where src/index.js features a signal handler for SIGINT. Now, docker stop <container> works perfectly.

This can easily be reproduced for other types of processes, so I hope it helps 😃

@montanaflynn it was able just open another tab from terminal and put: docker stop <container_id>

I agree with @cpuguy83 in that I don’t see a problem with docker here, the annoyance come from the fact that the signal is sent to /bin/sh. The very simple solution to this is use

sh -c "exec ping google.com"

which replaces the shell process with the ping process instead of

sh -c "ping google.com"

When using sh -c "exec ping google.com" the signal (Ctrl-C) is sent to ping opposed to sh. And ping does not ignore this signal when run as pid 1

Is it running inside a /bin/sh? If so, the signal is sent to /bin/sh, which ignores signals when run as pid 1.

No, /bin/sh doesn’t ignore Ctrl-C. Ping doesn’t ignore it either. The issue here is missing -t flag:

docker run -i $IMAGE

should’ve been

docker run -it $IMAGE

E.g.:

docker run --rm -it alpine sh -c "ping -c 4 google.com"

vs

docker run --rm -i alpine sh -c "ping -c 4 google.com"

vs

docker run --rm -ti alpine ping -c 4 google.com

vs

docker run --rm -i alpine ping -c 4 google.com

The kernel doesn’t ignore it, the process does.

@rolkar Because there are two foreground processes in this case. The process you’re attached to in the container and the docker client.

I personally think this should behave in much the same way as SSH, though with a different escape sequence. FYI SSH’s escape sequence is <enter>~.

Also for swarm mode:

The corresponding compose change was recently merged, so in the next version you’d be able to do this:

version: '3.7'
services:
  myservice:
    image: myimage
    init: true

Finally you won’t have to modify images just to add tini so that your containers aren’t killed (exit code 137) when not responding to SIGTERM. Especially useful for databases to prevent data loss.

Update: This has been answered here https://github.com/moby/moby/issues/37200

Real world use-case: running Docker container with tests inside CI with:

docker run -ti my-image my-test-script

The CI does not support TTY so I get:

the input device is not a TTY
stdin: is not a tty
ERROR: Job failed: exit status 1

How do I propagate a SIGTERM up to the container entrypoint when I don’t have a TTY?

My desired process tree:

ci-runner
  bash
    docker run -ti my-image my-test-script

CI runner will send a SIGTERM to the bash script that will propagate to the docker run but since there is no TTY support it can’t run with -ti.

This works in my terminal.

You’re starting apache using apache2-foreground but then daemonize it using & ?

Thanks, @cpuguy83, that makes it clearer. ping was indeed running under /bin/sh.

@Vanuan Yes, this is exactly as I said. The signal is still sent to the program, the program just doesn’t respond to it.

@lhazlewood Because the issue wasn’t about ctrl+pq it was about getting out of attach with ctrl-c, which is not supported since “attach” is litterally attaching you to the running process and should be expected behavior. If you just want the stdout+stderr streams you should use docker logs not attach. I see this as a training issue and not a Docker issue.

If we want to discuss changing ctrl-pq, and I know I’ve seen other issues around it that’s fine. I’m not sure that we can change it at this point. We talked about introducing a configurable command for it but was implemented server side and just wasn’t ideal and implementing it client-side is difficult.

And I write all this in the friendliest of tone, I’m terse by nature, sorry about that.