Container Killed: OOMKilled and Exit Code 137

A container starts, runs for a bit, then vanishes. docker ps -a shows:

Exited (137)

And docker inspect shows "OOMKilled": true. This almost never means your program crashed — it means the Linux out-of-memory (OOM) killer stepped in and terminated the process because it tried to use more memory than it was allowed.

What 137 actually means

Exit code 137 is 128 + 9. The 9 is signal SIGKILL — the process was force-killed from outside, not by its own error. When it's paired with OOMKilled, the killer is the kernel reclaiming memory.

Step 1: Confirm it was the OOM killer

docker inspect <container> --format '{{.State.OOMKilled}} {{.State.ExitCode}}'

true 137 is your confirmation. If it says false, the 137 came from something else sending SIGKILL (a docker kill, an orchestrator, a failing health check) — a different hunt.

Step 2: Find out how much it actually needs

Watch live usage against the limit before you guess a number:

docker stats <container>    # MEM USAGE / LIMIT, live

If usage climbs to the limit and then the container dies, you've found the ceiling.

Step 3: Raise the limit — or fix the leak

If the workload genuinely needs more, give it more:

docker run --memory=1g myapp        # or mem_limit: 1g in compose

Bumping the limit is the right call for a workload that legitimately needs the RAM. But if memory grows without bound over time, you have a leak — more memory just delays the same death. Profile the app instead of chasing the limit upward forever.

The Kubernetes version

Same signal, different words: pods show OOMKilled in kubectl describe pod, and you tune it with resources.limits.memory. The kernel mechanism underneath is identical.

The checklist

1. Exit 137 + OOMKilled: true → the kernel killed it for memory.
2. docker inspect to confirm it wasn't a different SIGKILL.
3. docker stats to see real usage vs the limit.
4. Raise --memory for a legit need; profile for a leak.