exec and attach — working inside a running container · Docker & Containers

docker exec is the command operators reach for the moment something looks wrong. It is also the command that produces the most misleading conclusions, because what you see and do inside an exec session is not quite what PID 1 sees, and nothing you change survives the next deploy.

This lesson is about what exec actually is, how it differs from attach, and which diagnoses drawn from an exec session you should distrust.

What exec is

Joining namespaces, not starting a container

docker exec asks the daemon to start an additional process inside an already-running container. The runtime places that process into the container’s existing namespaces — mount, PID, network, UTS, IPC — and into the container’s cgroup. It is the same mechanism as nsenter, wrapped in the Docker API.

Consequences that follow directly:

The new process is not PID 1. It gets whatever PID the container’s PID namespace hands out next.
It shares the container’s cgroup, so its memory and CPU count against the container’s limits, and it counts against --pids-limit.
It sees the container’s root filesystem, including the writable layer.
It sees the container’s network namespace, so curl localhost:8080 from an exec session reaches the container’s own listener.
It inherits the container’s Config.Env, plus anything you add with -e.
It runs as the image’s USER unless you pass -u.
When PID 1 exits, the container stops and your exec process is killed with it, whatever it was in the middle of.

The flags are few and worth knowing precisely: -i/--interactive keeps stdin open, -t/--tty allocates a pseudo-terminal, -d/--detach runs the command in the background, -e/--env and --env-file add environment, -u/--user and -w/--workdir change identity and directory, and --privileged gives the exec-ed process extended privileges. That is the whole list. There is no --cap-add on exec, and no way to change the network or mount namespace of the exec-ed process — it gets the container’s.

Read-only / Safeexec— Read a value from inside a running container.

$ docker exec web nginx -v

nginx version: nginx/1.27.4

Illustrative output

Note the absence of -it. You only need a TTY when something interactive is on the other end. docker exec -it web sh in a script that has no terminal fails with the input device is not a TTY, which is a startlingly common cause of red CI jobs.

What attach is

docker attach does something different and much narrower: it connects your terminal to the stdio streams of PID 1. It starts nothing. There is only ever one PID 1, so attach is a window onto the process that already exists.

That makes attach useful for a container that expects console input — a database REPL, an interactive installer — and dangerous everywhere else:

Read-only / Safelogs— The safe way to watch a container's output.

$ docker logs -f --tail 100 --timestamps web

2026-08-11T09:14:02.118374Z 192.0.2.44 - - [11/Aug/2026:09:14:02 +0000] "GET /health HTTP/1.1" 200 2
2026-08-11T09:14:12.119901Z 192.0.2.44 - - [11/Aug/2026:09:14:12 +0000] "GET /health HTTP/1.1" 200 2

Illustrative output

	`docker exec`	`docker attach`	`docker logs`
Starts a process	Yes	No	No
Talks to PID 1	No	Yes	Reads its output
Can signal PID 1	Only if you send one	Yes, by default	No
Works on a stopped container	No	No	Yes
Multiple concurrent sessions	Yes	Yes, they share the stream	Yes

Exec is not free

Because exec-ed processes live in the container’s cgroup and PID namespace, they are accounted for like any other container process.

A container with --pids-limit 64 that is already running 60 threads will refuse your docker exec ... bash, and the error — a fork failure — looks nothing like “you hit the PIDs limit”.
A memory-hungry diagnostic (jmap, a large grep -r) runs inside the container’s memory limit. It can trigger the OOM killer, and the kernel may well pick the application rather than your shell. You went in to diagnose an incident and caused a bigger one.
docker top shows the container’s processes with host PIDs, which is what you need if you want to attach a host-side profiler.

Read-only / Safetop— Container processes, listed with host PIDs.

$ docker top web

UID     PID     PPID    C   STIME   TTY   TIME       CMD
root    2192    2171    0   Aug07   ?     00:00:04   nginx: master process nginx -g daemon off;
101     2245    2192    0   Aug07   ?     00:01:13   nginx: worker process

Illustrative output

Healthchecks are execs

Every healthcheck the daemon runs is an exec. On a busy host you can watch them go past:

docker events --filter 'type=container' --filter 'event=exec_die'

This matters for two reasons. A healthcheck with a heavy command runs inside the container’s resource limits on every interval, and a container at its PIDs limit will start failing healthchecks for reasons that have nothing to do with the application’s health.

Everything you change is temporary

An exec session writes to the container’s writable layer. docker rm deletes that layer. Every replacement of the container — a deploy, a docker compose up after an image change, an Ansible run that recreates the container — throws it away.

Read-only / Safediff— What has been written to the writable layer since the container started.

$ docker diff web

C /etc
C /etc/nginx
C /etc/nginx/nginx.conf
A /root/.bash_history
C /var/cache/nginx

Illustrative output

docker diff is the honest audit of what somebody has been doing with exec. A is added, C is changed, D is deleted. A C on a configuration file is a change that exists on exactly one host, in exactly one container, and is about to vanish.

Debugging a container with no shell

Minimal and distroless images deliberately ship no sh, no ls, no curl. docker exec -it web sh fails:

OCI runtime exec failed: exec failed: unable to start container process:
exec: "sh": executable file not found in $PATH: unknown

That is not a broken container. It is the image doing its job. Two ways in:

A sidecar sharing the target’s namespaces. Start a throwaway container in the same network and PID namespaces, with tools installed:

Configuration changesidecar— Join the target container's network and PID namespaces from a container that has tools.

docker run --rm -it \
--network container:web \
--pid container:web \
--cap-add SYS_PTRACE \
nicolaka/netshoot

The sidecar shares the target’s network namespace, so ss -tlnp and curl see exactly what the application sees. --pid container:web lets you see the target’s processes and read /proc/1/environ. What the sidecar does not share is the mount namespace, so you cannot read the target’s files this way.

nsenter from the host, when you need the mount namespace too. Find the host PID first:

Read-only / Safepid— The host PID of the container's PID 1.

$ docker inspect --format '{{.State.Pid}}' web

Illustrative output

Service impact possiblensenter— Enter every namespace of the target, using the host's tools.

nsenter --target 2192 --mount --uts --ipc --net --pid -- ls -l /etc/nginx

nsenter runs the host’s binaries with the container’s namespaces, so you get a working ls even in a scratch image. It requires root on the host and it bypasses every restriction Docker applied to the container — treat it as a privileged operation and log it.

What exec is

What attach is

Exec is not free

Everything you change is temporary

Debugging a container with no shell

Knowledge check