Detach from Docker without stopping the container

For a Docker container created with interactive input and a TTY, press Ctrl+P, then Ctrl+Q to detach from its main-process session. Docker's client consumes that sequence and leaves the process running. It is not a universal escape sequence for every attached stream.

Check the session type

A simple example is:

docker run -it --name shell-demo alpine:3.22 /bin/sh

Press Ctrl+P followed by Ctrl+Q, then inspect the state from the host:

docker ps --filter name=shell-demo
docker attach shell-demo

The shell remains the container's main process. Typing exit when attached to it ends that shell and normally stops the container. Ctrl+C can send an interrupt through the TTY or signal proxy; the application's signal handling determines what happens.

Without the required interactive/TTY setup, Ctrl+P/Ctrl+Q may do nothing. Check OpenStdin and Tty with docker inspect, and avoid experimenting with interrupt keys on an important service.

Prefer detached startup for background services

docker run -d --name myapp myapp:1.2
docker logs -f --tail 100 myapp
docker exec -it myapp /bin/sh

These are separate commands for starting a service, viewing available logs, and opening a diagnostic shell. Stop the log viewer with Ctrl+C. Exit an exec shell with exit; that normally ends only the added shell, although commands executed there can still change or terminate the application.

The service's main process must remain in the foreground inside its container. -d detaches the Docker client; it does not keep a container alive after that main process exits.

Change conflicting keys

For an appropriate interactive session:

docker attach --detach-keys='ctrl-x' shell-demo

The run command also supports a per-session detach-key override. A terminal multiplexer or SSH client may intercept keys, so test the chosen sequence on a disposable container first. Changing the key does not create a TTY for a container that lacks one.

FAQ

How do I recover after accidentally stopping the service?

Inspect docker ps -a and its logs first. If restarting the same container is appropriate, use docker start myapp. For an existing interactive main-process session, docker start -ai shell-demo starts and attaches it again. A --rm container that was removed cannot be restarted by that name.

Will a restart policy bring it back automatically?

That depends on the policy, exit status, how it stopped, and daemon state. Manual stops suppress automatic restart according to Docker's policy rules; on-failure is different from always and unless-stopped. Verify the actual state rather than assuming recovery occurred.

Does Kubernetes use Docker's detach keys?

Do not carry a Docker CLI keyboard guarantee over to kubectl. Use the relevant client's documented behavior. For observation, kubectl logs -f avoids interacting with the application process.

See attach, start, and restart policies.