How do you troubleshoot a container that exits immediately?
Assesses fundamental understanding of Docker conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
A container stops when its main process exits, so first find out why the process ended.
- Inspect the exit code and state.
docker ps -a
docker inspect --format '{{.State.ExitCode}} {{.State.Error}}' web
Common codes: 0 means the process finished normally, often a misconfigured entrypoint that does not stay in the foreground; 1 is a generic application error; 137 indicates SIGKILL, often OOM, so check docker inspect for OOMKilled true; 126 or 127 mean the command was not found or not executable.
- Read logs from the crashed container with docker logs web.
- Run interactively to debug: docker run -it --entrypoint sh web.
- Check resource limits, missing environment variables, volume permissions, and whether the command runs in the foreground.
For daemons that background themselves, run them in the foreground, such as nginx -g 'daemon off;'.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.