Docker Error Guide: 'Container is restarting, wait until the container is running' — Fix Crash Loops
Fix Docker 'container is restarting, wait until the container is running': diagnose crash loops from restart policies, read logs and exit codes, and stop the restart cycle safely.
- #docker
- #troubleshooting
- #errors
- #restart-policy
Fixing errors like this? Get 500 free DevOps AI prompts
500 copy-paste AI prompts for the stack you actually run — one PDF, free.
Overview
Docker returns this when you try to exec into (or otherwise operate on) a container that is caught in a restart loop:
Error response from daemon: Container 7d2e4a91c3f0 is restarting, wait until the container is running
The container has a restart policy (always, unless-stopped, or on-failure), its main process keeps exiting, and the daemon keeps relaunching it. Between attempts the container is in the restarting state, and you cannot exec into a process that is repeatedly dying. The message is a symptom of a crash loop.
Symptoms
docker execfails withis restarting, wait until the container is running.docker psshows the status flickering —Restarting (1) 3 seconds ago— and the uptime never grows.- The
RestartCountindocker inspectclimbs steadily. - A Compose service with
restart: alwaysnever becomes healthy.
Common Root Causes
- The application crashes on startup and a restart policy relaunches it endlessly — a bad config, missing dependency, or failed migration.
- A dependency is not ready — the app exits because a database or upstream service it needs is not reachable yet.
- Non-zero exit combined with
restart: always— any failure is retried forever instead of surfacing. - Failed healthcheck causing external restarts — an orchestrator kills and recreates the container repeatedly.
- Resource limits too low — the process is OOM-killed shortly after start on each attempt.
- Bad entrypoint or command that exits immediately, retried by the policy.
Diagnostic Workflow
Confirm the state, restart policy, and how many times it has restarted:
docker ps --filter "id=7d2e4a91c3f0"
docker inspect --format 'status={{.State.Status}} restarts={{.RestartCount}} policy={{.HostConfig.RestartPolicy.Name}}' 7d2e4a91c3f0
Read logs across restarts — the loop reason repeats every cycle:
docker logs --tail 40 --timestamps 7d2e4a91c3f0
Check the exit code and whether the kernel is killing it:
docker inspect --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}}' 7d2e4a91c3f0
To break the loop so you can investigate calmly, stop the container (which disables further restarts until you start it) and relaunch with the policy off and the failing entrypoint replaced:
docker stop 7d2e4a91c3f0
docker run -it --rm --restart no --entrypoint sh myapp:1.4.2
For daemon-level clues on repeated kills:
journalctl -u docker --since '10 min ago' | grep -i '7d2e4a91c3f0\|oom'
Example Root Cause Analysis
A payments worker deployed with restart: always never stabilized. docker ps cycled through Restarting (1) and docker exec returned is restarting, wait until the container is running.
Inspecting showed a fast-growing restart count and a clean exit code of 1 (not an OOM):
docker inspect --format '{{.RestartCount}} {{.State.ExitCode}} {{.State.OOMKilled}}' worker
# 47 1 false
The logs, read across cycles, repeated the same line:
docker logs --tail 5 worker
# FATAL: could not connect to database "orders" at db.example.com:5432
The worker started before its database dependency and exited; the restart policy then hammered it. The fix was twofold: add a startup wait/retry with backoff inside the app so a not-yet-ready database no longer causes an immediate exit, and use restart: on-failure:5 instead of always so a genuine misconfiguration surfaces after a bounded number of attempts rather than looping forever.
Prevention Best Practices
- Prefer
on-failure:<n>overalwaysfor services that can fail permanently, so a broken build stops looping and becomes visible. - Implement dependency waits with backoff (or
depends_onwith healthchecks in Compose) instead of exiting when an upstream is not ready. - Add a
HEALTHCHECKand monitorRestartCountso crash loops trigger alerts early. - Set realistic memory limits and watch for
OOMKilledon restart. - Validate startup configuration and the entrypoint with the Dockerfile validator, and standardize runtime policies from the Docker stack guide.
Quick Command Reference
docker ps --filter "id=<id>"
docker inspect --format '{{.State.Status}} {{.RestartCount}} {{.HostConfig.RestartPolicy.Name}}' <id>
docker logs --tail 40 --timestamps <id>
docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' <id>
docker stop <id> # halts the restart loop
docker run -it --rm --restart no --entrypoint sh myapp:1.4.2 # debug calmly
Conclusion
This message means a restart policy is fighting a process that keeps dying. You cannot exec into a container that is mid-restart, so stop chasing the exec error and diagnose the loop: check RestartCount, read docker logs across cycles, and confirm the exit code and OOM status. Stop the container to freeze the loop, reproduce with --restart no, and fix the underlying crash — usually a missing dependency, bad config, or resource limit — before restoring the policy.
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.