Linux Exit Codes and Signals: Docker & Kubernetes Troubleshooting Library
Search by number or symptom. Type 137 or oom for a memory kill, 143 or sigterm for a shutdown problem, or 127 for a missing command. Every guide shows the proof commands first, then the three root causes that actually happen in production, then copy-ready Compose and Kubernetes configuration.
Search the exit code library
One input filters both tables instantly. It matches the exit number, the signal name, the observed status and the typical cause, so oom, exit 137, chmod and alpine all work.
Showing 18 guides.
No guide matches that search. Try a number such as 137, a signal such as SIGKILL, or a symptom such as OOM or command not found.
Exit codes: 0 to 255 and Docker conventions
Codes 0-124 are application-defined. 125 is Docker's own start-failure code, 126, 127 and 128 have shell or Docker meanings, 129-192 are signal terminations (128 + signal 1-64), and 255 covers SSH fatal errors and exit -1. Select the exact code to see proof commands and fixes.
| Exit Code | Signal | Typical cause | Fatal level | Guide |
|---|---|---|---|---|
| 0 | Success | Success: normal completion; restart policy or Job completions cause loops | Clean | Troubleshoot 0 → |
| 1 | General Error | General error: uncaught exception, bad config or missing secret | Warning | Troubleshoot 1 → |
| 2 | Shell Misuse | Shell syntax error: CRLF line endings or bash syntax under sh | Warning | Troubleshoot 2 → |
| 125 | Docker Run Failed | Docker start failure: port allocated, bad option or image pull | Fatal | Troubleshoot 125 → |
| 126 | Cannot Execute | Cannot execute: missing chmod +x, wrong architecture or noexec | Fatal | Troubleshoot 126 → |
| 127 | Command Not Found | Command not found: missing binary, Alpine bash or glibc loader | Fatal | Troubleshoot 127 → |
| 128 | Invalid Exit Argument | Invalid exit argument: -1 wrap or unvalidated status | Warning | Troubleshoot 128 → |
| 129 | SIGHUP | SIGHUP: terminal close or reload without a handler | Warning | Troubleshoot 129 → |
| 130 | SIGINT | SIGINT: Ctrl+C in an interactive session or explicit interrupt | Warning | Troubleshoot 130 → |
| 137 | SIGKILL | OOMKilled: memory limit exceeded or failed liveness probe | Fatal | Troubleshoot 137 → |
| 139 | SIGSEGV | SIGSEGV: native segfault, cgo crash or libc/ABI mismatch | Fatal | Troubleshoot 139 → |
| 143 | SIGTERM | SIGTERM: graceful stop request or grace-period timeout | Warning | Troubleshoot 143 → |
| 255 | Exit Out of Range | Exit -1 or SSH fatal connection/authentication error | Fatal | Troubleshoot 255 → |
Signal reference: fatal signals and exit status
The parent sees 128 plus the signal number. These pages explain how each signal is delivered, what Docker and Kubernetes do with it, and which handlers are safe to install.
| Signal | Number | Observed exit | Default action | Fatal level | Guide |
|---|---|---|---|---|---|
| SIGHUP | 1 | 129 | Terminate | Warning | Signal guide → |
| SIGINT | 2 | 130 | Terminate | Warning | Signal guide → |
| SIGKILL | 9 | 137 | Terminate (cannot be caught, blocked or ignored) | Fatal | Signal guide → |
| SIGSEGV | 11 | 139 | Terminate with core dump | Fatal | Signal guide → |
| SIGTERM | 15 | 143 | Terminate | Warning | Signal guide → |
The 128 + n rule, and where it stops applying
A process terminated by a fatal signal is reported by its parent shell as 128 + signal number. This is a shell convention, not a kernel exit status: the kernel records a wait status, and the shell maps the terminating signal into that 128+n range.
129 = 128 + 1— SIGHUP, terminal hangup or a reload that had no handler.130 = 128 + 2— SIGINT, usually Ctrl+C in an interactive session.137 = 128 + 9— SIGKILL, the cgroup OOM killer, a failed liveness probe after the grace period, or an explicitkill -9.139 = 128 + 11— SIGSEGV, a native memory fault, not an out-of-memory kill.143 = 128 + 15— SIGTERM, the default graceful stop request for Docker, Kubernetes and systemd.
The rule does not make 125, 126, 127 or 255 signal codes. Those come from Docker, the shell or SSH and have their own meanings. If a status is not in the 129-192 range and the process was not killed, treat it as an application or runtime status and read the sender's documentation rather than the signal table.
The defensible workflow is always the same: read the runtime's recorded status, confirm whether a signal was involved, identify the sender, then change the configuration that caused it. Guessing from the number alone is how a memory limit gets raised when the actual cause was a shell that never forwarded SIGTERM.
Frequently asked questions
How do I tell an OOM kill from a normal shutdown?
Exit 137 is SIGKILL, but the sender matters. Run docker inspect <id> --format '{{.State.OOMKilled}}' or read the Kubernetes lastState reason. OOMKilled true means the cgroup memory limit was exceeded; reason Error with a failed liveness probe means the kubelet escalated after the grace period. Exit 143 is the SIGTERM stop request, not an OOM kill.
Why is the exit code 128 + n?
Shells encode a signal termination as 128 plus the signal number so it cannot be confused with a normal 0-127 application status. SIGKILL is 9, so 137; SIGTERM is 15, so 143. The kernel's wait status is different, but the shell and most container tools present the 128+n value.
Does Kubernetes use Docker exit codes?
Kubernetes records the container process status and reason in .status.containerStatuses[].lastState.terminated. The numeric meanings match the process and signal conventions described here, but start failures are reported as pod events such as FailedScheduling, ErrImagePull or FailedMount rather than as exit 125.
What should I check first when a container restarts?
Get the last exit code, the reason and whether OOMKilled is true, then read the previous container logs. Those three facts separate a signal kill from an application failure and from a runtime start failure. Change the configuration that matches the evidence instead of raising memory or restart counts blindly.
Related network and developer references
Reference basis: POSIX signal semantics, Docker container exit status conventions and Kubernetes container termination behaviour. Always confirm the exit status against the runtime version in use; distro and orchestrator behaviour can differ.
Last reviewed 2026-11-06 · All ports · Developer tools · Privacy