The one everybody arrives with
SIGKILL, from either the OOM killer or a stop timeout, and they need different fixes
137
Paste the number from docker ps -a. The one people arrive with is 137, and it is two entirely different problems wearing the same number.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Explain. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
SIGKILL, from either the OOM killer or a stop timeout, and they need different fixes
137
SIGTERM, handled properly. This is what a correct shutdown looks like
143
Three likely causes, and none of them is a missing file
126
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It is SIGKILL, which is also what docker stop sends after the grace period. Raising the memory limit for a shutdown problem changes nothing.
Instead:Check docker inspect --format '{{.State.OOMKilled}}' first. False means the process is ignoring SIGTERM.
No container was created, so there are no logs. The error is on the output of the run command itself.
Instead:Read the command's own output. It names the flag or the conflict.
The file was found. It could not be executed, which is usually a missing execute bit, Windows line endings, or a shebang naming an interpreter the image does not have.
Instead:chmod +x in the Dockerfile, check the line endings, and confirm the interpreter exists.
125, 126, 127 and everything above 128 come from Docker or the kernel. Anything else was chosen by the program, and Docker knows nothing about what it means.
Either the kernel's OOM killer ended the process because the container hit its memory limit, or docker stop timed out after the grace period and Docker escalated from SIGTERM. Those need completely different fixes. docker inspect --format '{{.State.OOMKilled}}' is the deciding field: true means memory, false means your process ignored SIGTERM, which usually means a shell at PID 1.
125 means the docker command itself failed and no container was created, so the error is on the command's own output. 126 means the file was found and could not be executed: not executable, CRLF line endings, or a shebang pointing at something absent. 127 means the file is not there at all, which on a distroless base is usually a shell that was never in the image.
So 143 is SIGTERM, which is a clean stop and the code you want to see. 139 is SIGSEGV, which in a container is often an architecture mismatch or a glibc binary on an Alpine base. 130 is Ctrl-C.
It is a generic non-zero chosen by the program. Docker records it and knows nothing more, so the logs are the only source.
The kernel ends the process immediately: no signal handler, no flush, no final line. The log stops mid-sentence, which is itself the clue.
Which is why a container with on-failure that exits zero is not restarted, and why a wrapper script swallowing a failure turns a restart loop into silence.