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
Stuck on this Docker with AI error? Get the free incident triage checklist
A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.
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.
Fixed it? Get 500 Docker with AI & 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.
Stuck on this? Start guided troubleshooting
Open an interactive diagnostic session with this error already loaded. Work a step-by-step plan, record what each check returns, land on a root cause, and export a clean incident summary — no account needed to start.
Did this fix your issue?
Solved it a different way?
Share the fix that worked for you — reviewed, then published to help the next engineer.
That looks like it may contain a secret (key, token, password, or connection string). Please remove it — a note with a detected secret can’t be published.
Thanks — that helps. Published notes appear after a quick review.
Trending errors this week
The error guides other engineers are actually reading right now.
- 1mount: wrong fs type, bad option, bad superblock
- 2Docker 'failed to set up container networking': Fix the Bridge and IP Pool
- 3Docker 'failed to create shim task': How to Fix the containerd Runtime Error
- 4Transport endpoint is not connected
- 5modprobe: FATAL: Module not found
- 6mount: wrong fs type, bad option, bad superblock
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.