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.