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.