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

Many Docker beginners encounter containers that start and then immediately stop, showing no error logs. The reason is not a mistake in the Dockerfile but the way Docker runs: it launches the command quickly and exits if the main process finishes.

Using the official Nginx Dockerfile as an example, the

CMD

runs Nginx with

daemon off

. This is necessary because if Nginx runs in background mode, the start command finishes, causing the container to exit.

In Linux, after the kernel boots it starts the

init

process, which has PID 1. All other user‑space processes are its children, forming a process tree. The init process maintains process table entries, and when a child exits it must be reaped with

wait

/

waitpid

. If a child exits without being reaped, its entry becomes a zombie; if the parent exits first, the child becomes an orphan and is adopted by init (PID 1), which cleans up its resources.

Inside a Docker container there is no real init process; the process marked as PID 1 is just a regular user process. When you run

docker run -d nginx

, the process defined by

CMD

becomes PID 1 inside the container. If that process terminates, Docker treats the container as finished and stops it.

The container’s process tree is actually a branch of the host’s process tree. The top‑level process is

containerd‑shim

(shown as PID 0 in the container), which creates the container and then hands control to the entrypoint process. The

runC

runtime creates the container and exits, so you typically see

containerd‑shim → entrypoint

without a visible

runC

process.

Understanding these Linux PID 1 concepts and Docker’s runtime architecture explains why containers often exit immediately after starting.