Step-by-Step Fix: Docker Container Exits Immediately After Starting

1Read the exit code

Run docker ps -a. Look at the STATUS column:

Exited (0)  → process finished normally (often missing foreground)
Exited (1)  → app threw an error — read logs
Exited (125)→ Docker daemon failed
Exited (126)→ command not executable (chmod +x missing)
Exited (127)→ command not found (typo or wrong PATH)
Exited (137)→ OOM killed — raise memory limit

Exit code tells you which branch of the fix to take before you even read logs.

2Pull the logs

Every exited container leaves logs behind until you docker rm it:

docker logs --tail 50 <id>
docker logs --timestamps <id>

Common culprits you'll see: EADDRINUSE (port conflict), MODULE_NOT_FOUND (bad COPY path), permission denied (entrypoint script not executable), or silent empty output (foreground problem — see step 3).

3Fix the foreground process

Most common cause. A container lives exactly as long as PID 1 lives. Bad Dockerfile:

CMD service apache2 start

Apache forks to background, CMD returns, container dies. Fix:

CMD ["apache2ctl","-D","FOREGROUND"]
# or for nginx:
CMD ["nginx","-g","daemon off;"]
# or python:
CMD ["python","-u","app.py"]

4Debug interactively

When logs don't reveal it, crack the image open:

docker run -it --entrypoint sh myimage
# inside:
ls -la /app
cat /entrypoint.sh
which node
echo $PATH

This bypasses your CMD entirely. You can manually run your startup command and watch it fail in real time. Also check line endings — \r\n in entrypoint scripts (Windows → Linux) causes silent death. Run dos2unix entrypoint.sh.

Windows line endings in entrypoint

If you built the image on Windows and your entrypoint.sh has CRLF line endings, Linux tries to execute /bin/bash\r — which doesn't exist. Container exits 127 with a cryptic "no such file" error even though the file is right there.

RUN sed -i 's/\r$//' /entrypoint.sh \
 && chmod +x /entrypoint.sh

docker-compose "restart: always" masking the error

If your compose file has restart: always, the container will crash-loop and you'll see it in docker ps looking alive. Run docker compose logs --tail 100 service_name to see the repeated startup failures. Temporarily set restart: "no" while debugging.

FAQ — Docker container exit codes (2026)

What does exit code 0 vs 1 mean?

Exit 0 = process finished cleanly (often because PID 1 backgrounded itself — Docker had nothing to keep alive). Exit 1 = app threw an uncaught error and crashed; check docker logs for the trace.

What does exit 137 mean?

SIGKILL — almost always OOM. Raise the limit with docker run --memory=2g, or check Docker Desktop → Resources → Memory (default 2GB caps Node/JVM workloads).

What does exit 127 mean?

Command not found. Three causes: typo in CMD, missing binary in image (alpine lacks bash by default), or CRLF line endings in entrypoint.sh making Linux look for /bin/bash\r. Fix with RUN sed -i 's/\r$//' /entrypoint.sh.

FAQ — ENTRYPOINT vs CMD & foreground

ENTRYPOINT vs CMD — which to use?

ENTRYPOINT = the binary that always runs. CMD = default args (overridable at run-time). For single-purpose containers, ENTRYPOINT ["node","server.js"] is cleanest. CMD-only is a common cause of "exits immediately" because docker run image arg1 replaces the whole CMD.

How do I keep PID 1 in foreground?

Never use service start, systemctl, or backgrounding. Use daemon-off forms: CMD ["nginx","-g","daemon off;"], CMD ["apache2ctl","-D","FOREGROUND"], or CMD ["python","-u","app.py"] (-u streams logs live). For interactive testing only: tail -f /dev/null.