A restart loop tells you more than people realise, and the exit code narrows it down before you read a single log line.
Exit 0 — it finished successfully. The process did its job and returned. This is not a crash; it is a container running something that was never meant to be a long-lived service, or a main process that daemonised itself into the background and left the foreground empty. Docker keeps the container alive only as long as PID 1 runs. If your entrypoint ends with something that forks and returns, that is the bug.
Exit 1 — the application rejected its configuration. Nine times out of ten this is a missing environment variable, a config file that is not where the image expects it, or a permission problem on a mounted volume. Read the last 30 lines and it is usually the first error printed, not the last:
Exit 137 — killed with SIGKILL, almost always the OOM killer. Confirm it:
If that prints
Exit 143 — SIGTERM, a clean shutdown request. This is normal on
When there is no useful log at all
Some images log to a file inside the container instead of stdout, so
That gives you a shell in the same image without the failing entrypoint, so you can look at what the config actually says.
The loop that hides itself
Watch for a container that restarts every 30–60 seconds, each time getting far enough to serve a request or two. Uptime monitors report it as flapping, users report "the site is slow sometimes", and nobody looks at Docker because the container status reads
Code:
docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}}' mycontainerExit 0 — it finished successfully. The process did its job and returned. This is not a crash; it is a container running something that was never meant to be a long-lived service, or a main process that daemonised itself into the background and left the foreground empty. Docker keeps the container alive only as long as PID 1 runs. If your entrypoint ends with something that forks and returns, that is the bug.
Exit 1 — the application rejected its configuration. Nine times out of ten this is a missing environment variable, a config file that is not where the image expects it, or a permission problem on a mounted volume. Read the last 30 lines and it is usually the first error printed, not the last:
Code:
docker logs --tail 50 mycontainerExit 137 — killed with SIGKILL, almost always the OOM killer. Confirm it:
Code:
docker inspect --format '{{.State.OOMKilled}}' mycontainerIf that prints
true, the container hit its memory limit. If it prints false and you still got 137, something outside sent a SIGKILL — usually a person, or an orchestrator, or the host's own OOM killer picking your process because the host ran out of memory. Those two cases have opposite fixes: the first needs a higher limit, the second needs a lower one on something else.Exit 143 — SIGTERM, a clean shutdown request. This is normal on
docker stop. It becomes a symptom when it happens repeatedly and you did not ask for it: a health check marked the container unhealthy and something restarted it, or a deploy tool is cycling it.When there is no useful log at all
Some images log to a file inside the container instead of stdout, so
docker logs is empty and you are blind. Get inside the filesystem of a container that will not stay up:
Code:
docker run --rm -it --entrypoint sh myimage:latestThat gives you a shell in the same image without the failing entrypoint, so you can look at what the config actually says.
The loop that hides itself
Watch for a container that restarts every 30–60 seconds, each time getting far enough to serve a request or two. Uptime monitors report it as flapping, users report "the site is slow sometimes", and nobody looks at Docker because the container status reads
Up 12 seconds whenever you check. docker ps showing a suspiciously young uptime on a service you deployed weeks ago is the tell.