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

Many Docker beginners encounter containers that start and then immediately stop, often without obvious error messages. The reason is not a mistake in the Dockerfile but the way Docker executes processes.

Using the official nginx Dockerfile as an example, the CMD is set to run nginx in daemon off mode instead of using systemctl nginx start or /etc/init.d/nginx start. Running nginx as a background daemon would cause the start command to exit, and Docker would then stop the container because the PID 1 process has finished.

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

Process Table Entry : The kernel tracks each process in a table. When a process ends, its resources are released, but the table entry remains until the parent calls wait / waitpid to retrieve the exit status.

Zombie Process : A process that has terminated but whose parent has not yet called wait, leaving its entry in the process table.

Orphan Process : A process whose parent exits before it; the orphan is adopted by the init process (PID 1), which then reaps it.

In Docker containers, there is no separate init process; the process marked as PID 1 inside the container is simply 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 give this process its own PID 1, isolating it from the host’s process tree. If you kill the PID 1 process on the host, the entire container stops, which explains why containers exit when the command finishes.

Observations show that inside the container the parent PID appears as “0”. This is because the container’s process tree is a branch of the host’s tree; the actual parent on the host is the containerd-shim process.

The container creation flow is docker-containerd-shim → runC → entrypoint. The runC process implements the OCI (Open Container Initiative) runtime specifications, interacts with cgroups and namespaces, and exits after setting up the container, which is why it is not visible in the final process list.

Understanding these mechanisms clarifies why Docker containers may start and then immediately exit when the foreground command terminates.