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.