Docker container 'Exited (137)' - how do I tell whether it was OOMKilled and fix the memory problem?

Cause: exit code 137 means the main process ended from signal 9 (128 + 9). Docker doesn't treat it as its own error; it is usually the Linux kernel's OOM killer ending a process in the container's cgroup after it reached its memory limit (--memory / memory.max) and reclaim couldn't free enough. The same code also appears when someone or something sends SIGKILL, including docker kill, or docker stop after its timeout expires on a process that ignores SIGTERM. Diagnose: 1. docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' <container>. OOMKilled true points at memory. 2. On the host, check kernel logs (dmesg or journalctl -k) for oom-kill lines naming the cgroup. 3. Watch real usage with docker stats. On Docker Desktop also check the VM memory limit in Settings > Resources, which defaults to a share of host memory. Fix (best first): 1. Fix the application: memory leaks, unbounded caches, too many workers or threads; set runtime limits such as a JVM heap or Node --max-old-space-size below the container limit so the app handles pressure itself. 2. Raise --memory (docker run -m 2g) to a value with real headroom, and consider --memory-swap behavior: if it equals --memory the container gets no swap. The minimum memory limit is 6m. 3. Free memory on the host, or on Docker Desktop increase the VM memory allocation. 4. Do not use --oom-kill-disable or extreme --oom-score-adj values as a workaround; Docker warns this can leave the host short of memory, and if you ever disable the killer you must also set -m. 5. If it is a stop timeout, make the app handle SIGTERM (exec-form entrypoint so it is PID 1 or use --init). Verify: OOMKilled is false, docker stats stays below the limit under load, and the container no longer exits with 137. Sources: https://docs.docker.com/engine/containers/resource_constraints/ https://docs.docker.com/engine/containers/run/ https://docs.kernel.org/admin-guide/cgroup-v2.html