Exit code 137: The process was killed with SIGKILL

Exit code 137 means a process was terminated by SIGKILL. In Kubernetes this is usually an out-of-memory kill, but it is also what you see when a container ignores SIGTERM and is force-killed at the end of its grace period.

Applies to: All Kubernetes versions, Linux nodes

What it means

Container exit codes above 128 encode a signal: the code is 128 plus the signal number. 137 is 128 + 9, and signal 9 is SIGKILL, which cannot be caught, blocked, or ignored by the process. So 137 tells you the process was terminated forcibly by something outside it — but not by what. The two common sources in Kubernetes are the kernel OOM killer acting on a container that hit its memory limit, and the kubelet force-killing a container that did not exit within terminationGracePeriodSeconds after receiving SIGTERM. These have completely different fixes, so the exit code alone is not enough to act on.

Most common causes

• The container hit its memory limit and the kernel OOM killer terminated it. The termination reason will read OOMKilled.
• The container was asked to stop, ignored or was too slow to handle SIGTERM, and was force-killed after the grace period expired.
• Something inside the container sent SIGKILL to the main process — for example a supervisor or an init script.
• On a node under severe memory pressure, the kernel OOM killer may act even on containers below their own limits.

How to diagnose it

1. Read the termination reason, not just the code: kubectl describe pod POD and look at Last State. Reason: OOMKilled settles it.
2. If the reason is not OOMKilled, check whether the kill happened during a deployment, scale-down, or node drain — that points at the grace period rather than memory.
3. Check how long the application takes to shut down and compare it with terminationGracePeriodSeconds, which defaults to 30.
4. Check node-level memory pressure with kubectl describe node NODE if several unrelated pods are being killed at once.

How to fix it

1. If it is an OOM kill, raise the memory limit or reduce usage, and confirm the application's runtime respects the cgroup limit.
2. If it is a slow shutdown, make the application handle SIGTERM and exit promptly, or raise terminationGracePeriodSeconds to cover the real drain time.
3. If the application never sees SIGTERM because it runs under a shell, use the exec form of the entrypoint or add a proper init process so signals are forwarded to PID 1.
4. If several unrelated pods are dying, treat it as a node capacity problem rather than an application problem.

Notes

The related code 143 is 128 + 15, meaning SIGTERM — a clean stop request that the process honoured. Seeing 143 during a rollout is normal and is not an error.

Related

• OOMKilled — Killed by the kernel for exceeding the memory limit
• Exit code 143 — Process terminated by SIGTERM

Sources

• Kubernetes documentation — Pod Lifecycle: container states and termination
• Kubernetes documentation — Resource Management for Pods and Containers