A container exits immediately on start. How do you debug it?

Question

Accepted Answer

First I keep in mind that a container lives only as long as its main process: when that process exits or crashes, the container stops, there is nothing else holding it open. So I look at what that process did. docker logs shows its stdout and stderr, which usually contains the error or stack trace, and docker ps -a with docker inspect gives me the exit code, which is often diagnostic on its own, for example 137 means it was SIGKILLed, typically an out-of-memory kill. If it dies too fast to inspect, I override the entrypoint to drop into a shell, docker run -it --entrypoint sh on the image, and run things by hand to see what fails, or exec in if it stays up for a moment. Then I check the usual suspects: a command that simply runs and finishes instead of staying in the foreground, a missing environment variable or config file, a wrong path or permission, a startup crash, or the main process being backgrounded so PID 1 exits and takes the container with it. The principle is to diagnose from logs, exit code, and an interactive shell rather than blindly restarting.

Answer

A container exits with code 137. What does that tell you?

137 = 128 + 9, killed by SIGKILL, most often an out-of-memory kill (exceeded the memory limit) or a forced stop. Check memory limits/usage and the OOM killer.

Answer

How do you get a shell in a container that crashes instantly?

Override the entrypoint: docker run -it --entrypoint sh (or bash) <image>, which starts a shell instead of the failing command so you can inspect the filesystem, env, and run the command manually.

A container exits immediately on start. How do you debug it?

A container exits immediately on start. How do you debug it?

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with docker

Knowing the answer is not the same as recalling it under pressure