6.1.2.5 Process Supervision Expectation
A focused guide to Process Supervision Expectation, connecting core concepts with practical Docker and container operations.
Process supervision expectation refers to the assumption, built into how containers are designed to operate, that something outside the container — Docker itself, or an orchestrator — handles restarting a failed main process, rather than the container running its own internal supervisor process to manage that responsibility.
Why Containers Typically Don't Need an Internal Supervisor
Traditional servers often run a process supervisor (systemd, supervisord) to automatically restart a crashed service; in a containerized environment, Docker's own restart policy, or an orchestrator's equivalent mechanism, typically fills this role instead, making an internal supervisor process usually unnecessary and sometimes actively counterproductive.
docker run -d --restart=unless-stopped myapp:1.0
This restart policy handles the case where the main process crashes, restarting the container automatically, without needing any supervisor process running inside the container itself.
The Problem With Running an Internal Supervisor Anyway
Running a supervisor process inside the container, managing the actual application as a child process, undermines the foreground process model — the supervisor itself becomes the container's main process, while the actual application's exit status becomes invisible to Docker, since the supervisor (not the application) is what Docker is actually watching.
CMD ["supervisord", "-c", "/etc/supervisor/supervisord.conf"]
If the actual application crashes repeatedly inside this setup, Docker has no direct visibility into that, since the supervisor process itself continues running regardless.
When an Internal Process Manager Is Still Appropriate
For containers genuinely needing to run multiple cooperating processes (an unusual but occasionally legitimate pattern), a lightweight process manager designed for this specific purpose, that properly forwards signals and exit status, can be appropriate — but this is the exception, not the typical case.
CMD ["tini", "--", "my-multi-process-launcher.sh"]
Why This Expectation Matters
Designing a container around the assumption that external supervision (Docker's restart policy, an orchestrator's equivalent) handles process failure, rather than duplicating that responsibility inside the container, keeps the container's main process directly and transparently tied to the actual application's health.