What's the difference between docker exec and docker attach?

5 minintermediatedocker-execdocker-attachdebugging

Quick Answer

docker exec starts a brand-new process inside an already-running container's namespaces — most commonly used to open a debugging shell session alongside the container's actual main process, without disturbing it. docker attach instead connects your terminal directly to the container's existing main process's stdin/stdout/stderr streams — you're viewing/interacting with the one process that's already running, not starting a separate one, and exiting an attached session (via Ctrl+C, depending on configuration) can accidentally stop the container's main process entirely.

Detailed Answer

docker exec — a new, separate process inside the container

docker exec -it my-container sh

This starts a brand-new process (a shell, in this example) running inside the same namespaces as the container's existing main process. You get an independent, separate session for poking around — checking files, running diagnostic commands, inspecting environment variables — entirely alongside whatever the container's actual main process (say, a running web server) is doing. Exiting this shell session (exit, or Ctrl+D) simply ends that one exec'd process. The container's real main process, and the container itself, are completely unaffected and keep running exactly as before.

docker exec my-container ps aux
# shows the container's main process AND the exec'd command, as separate processes

docker attach — connects to the existing main process directly

docker attach my-container

This doesn't start anything new — it connects your terminal's stdin/stdout/stderr directly to the container's already-running main process (whatever was originally started by docker run/CMD/ENTRYPOINT). You're now seeing exactly what that one process is outputting, and if it accepts stdin input, whatever you type goes directly to it.

Why attach is riskier for casual investigation

docker attach my-container
# Ctrl+C
# this can send SIGINT directly to the container's main process --
# potentially stopping (or crashing) the very container you meant to just "look at"

Because attach connects to the actual main process, a Ctrl+C intended to just "detach and stop looking" can instead be interpreted as a signal sent to that process, potentially terminating it (and thus the container) entirely. This is a well-known, easy-to-trigger mistake for anyone using attach casually. (The correct way to detach without stopping the process is a specific escape sequence, Ctrl+P then Ctrl+Q, which most people don't remember under pressure.)

Why exec is almost always the right tool for debugging

docker exec -it my-container sh

Because exec starts an entirely separate process, there's no risk of accidentally disturbing the container's actual main workload just by exploring inside it. Exiting the exec'd shell is always safe, and never affects the container's real running process. This is exactly why docker exec -it <container> sh (or bash, if available) is the standard, go-to command for interactively debugging a running container. docker attach is reserved for the narrower, specific case where you genuinely want to interact with, or observe live output from, the container's actual main process itself — for example, a process that reads commands from stdin directly, where you specifically want to send it input. Remember the Ctrl+P, Ctrl+Q detach sequence if you do.

Related Resources