6.1.2.1 Container Main Process

A container's main process is the single process Docker considers responsible for the container's overall lifetime — typically assigned process ID 1 within the container's own PID namespace — whose continued running (or exit) directly determines whether the container itself is considered running or stopped.

Identifying the Main Process

The main process is whatever the image's ENTRYPOINT and CMD instructions (or their run-time overrides) ultimately specify as the container's startup command.

CMD ["node", "server.js"]

docker exec myapp ps aux

This typically shows the node server.js process running as PID 1 within the container, identifying it as the container's main process.

Why the Main Process's Exit Stops the Container

When the main process exits, for any reason, Docker considers the container itself to have stopped, regardless of whether other background processes might still technically be running within the container's namespace.

CMD ["sh", "-c", "node server.js &"]

This is a common mistake: backgrounding the actual application process means the shell itself becomes the main process, and the shell exiting (which can happen almost immediately) stops the container even while the backgrounded application continues running briefly, orphaned, until the container's namespace is torn down.

Why Running the Application Directly Matters

Running the application directly as the main process, rather than through an intermediate shell or wrapper that might exit independently of it, ensures the container's running state accurately reflects whether the actual application is still active.

CMD ["node", "server.js"]

Why Understanding the Main Process Matters

A clear understanding of exactly which process Docker considers a container's main process — and how that determines the container's own running status — is essential for correctly designing a Dockerfile's startup behavior and for accurately diagnosing why a container might be stopping unexpectedly.