Docker interview question · Most asked
How do you debug a container that exits immediately or behaves differently in production?
Summary
Check the exit code and logs (docker ps -a, docker logs <id>, docker inspect for state and OOMKilled), run it interactively with an overridden entrypoint (docker run -it --entrypoint sh image), and compare its environment, configuration, mounts, user and architecture with what you expect.
Longer Answer
Frequent causes: the main process runs in the background and the container exits (the main process must stay in the foreground); missing environment variables or config files; file permissions when running as non-root; wrong CPU architecture (exec format error when an arm64 image runs on amd64); and localhost assumptions. For running containers, docker exec -it <id> sh (or docker debug for images without a shell) lets you inspect from inside.
Key Points
- Exit code, logs, inspect.
- Override entrypoint to explore.
- Foreground process; env; permissions; arch.
- exec or docker debug into running containers.
More most-asked Docker questions
- What is the difference between an image and a container, and how do image layers work?
- What is a container, and how does it differ from a virtual machine?
- What are multi-stage builds, and why use them?
- CMD or ENTRYPOINT: what is the difference, and what are exec and shell forms?
- How does Docker build caching work, and how do you order a Dockerfile to use it well?
- What are Dockerfile best practices for production images?
- ARG or ENV: what is the difference, and how do you pass secrets into a build safely?
- How do you secure Docker containers and images?