Why Do Docker Containers Exit Instantly? Understanding PID 1 and Daemon Modes

Many Docker beginners find that their containers stop right after they start, even though the Dockerfile looks correct and no error logs appear.

The reason is not a mistake in your commands but the way Docker runs processes: it starts the container very quickly.

Using the official Nginx Dockerfile as an example, the

CMD

is set to run Nginx in the foreground with

daemon off

instead of using

systemctl nginx start

or

/etc/init.d/nginx start

. If Nginx were started as a background daemon, the start command would exit, causing the container to exit as well.

To understand why the container exits when the command finishes, we need to look at the Linux kernel. After initialization, the kernel launches the init process (PID 1), which becomes the parent of all user‑space processes. Concepts to know include:

Process table entry – each process occupies a slot in the kernel’s process table, storing its state, open file descriptors, etc.

Zombie process – a process that has terminated but whose parent has not yet called

wait

/

waitpid

to collect its exit status.

Orphan process – a process whose parent exits first; it is adopted by the init process (PID 1) which then reaps it.

PID 1 is responsible for cleaning up abandoned processes and reclaiming system resources, ensuring long‑term stability.

In a Docker container there is no full Linux init system; the process marked as PID 1 is just a regular user process. When you run

docker run -d nginx

, the process defined by the Dockerfile’s

CMD

becomes PID 1 inside the container.

Docker uses Linux PID namespaces to make the container’s process appear as PID 1, even though on the host it has a different PID. The container’s process tree is a branch of the host’s process tree.

If you kill the host PID of that process, the entire container stops, which explains why the container exits when the command finishes.

Inside the container, tools like

ps

may show the parent PID as “0”. This is because the container’s process tree is a subtree of the host’s tree, and the host’s

containerd‑shim

process appears as PID 0 from the container’s perspective.

Docker’s architecture includes

containerd‑shim

, which spawns a

runC

process to create the container.

runC

implements the OCI (Open Container Initiative) runtime specification, interacts with cgroups and namespaces, and then exits, leaving only

containerd‑shim

and the container’s entrypoint process visible.

Understanding these details explains why containers often exit immediately after start if the CMD process terminates.