Exit code 137 is the kernel collecting on a bet you did not know it placed

The useful question after a 137 is not why the application asked for so much memory. It is which of the two killers fired, because they have different triggers and neither fix lives in the application repo ^[11][12].

Start with the bet. When a process calls `malloc()`, the kernel usually hands back a virtual address range without checking that physical memory exists to back it, a behaviour called overcommit and controlled by `vm.overcommit_memory`, which defaults to heuristic mode 0 ^[3][4]. The reason is `fork()`: a process holding 4GB of RSS that forks would, under strict accounting, have to reserve a second 4GB it will almost certainly never touch because of copy-on-write ^[5]. That is 8GB booked to run one 4GB workload ^[1], and refusing the fork would break an enormous amount of software that relies on cheap forking ^[5]. So the kernel defers the reckoning until pages are actually touched rather than requested ^[6].

The deferral is why there is nothing to catch. When the kernel genuinely cannot satisfy a page fault, something has to die immediately and synchronously inside the page allocation path ^[6], which is why the process gets a SIGKILL with no exception, no core dump and no shutdown hook ^[1], and why the only trace on a host-level kill is one line in `dmesg` ^[2].

Victim selection is the part that decides how long the incident runs. The kernel does not kill the process whose allocation pushed the system over the edge; it kills whichever process scores worst on a badness heuristic, readable at `/proc/<pid>/oom_score` ^[7]. That score is roughly resident memory plus swap as a share of total system memory, then adjusted by `oom_score_adj`, a value from -1000 to 1000 that defaults to 0 ^[8]. A process pinned at -1000 is treated as unkillable and survives even while using 90% of RAM, which is how `sshd` and `systemd` stay up so you can log in afterwards ^[9]. Read that in reverse: anything in your critical path that has never been killed has been surviving because it happened to be smaller than a noisier neighbour, unless somebody set the adjustment on purpose ^[8][9].

Inside a container the denominator changes. Kubernetes writes a memory limit as `memory.max` in the pod's cgroup v2 hierarchy, and when the cgroup's usage crosses that ceiling the kernel runs an OOM kill scoped to processes in that cgroup alone ^[10]. Host memory is irrelevant to that decision, which is why a pod dies while `free -h` on the node looks comfortable ^[11]. On bare metal or a plain VPS the victim pool is every process on the box instead ^[14].

Hence the one diagnostic that matters. Host kills surface through `dmesg -T | grep -i 'killed process'`; cgroup kills surface through `journalctl -k` and the `oom_kill` counter in `memory.events` under the cgroup path ^[12]. A climbing `oom_kill` counter alongside a flat node memory graph is a limit set too tight, not a leak ^[13]. Check the counter first and the fix is a number in a manifest; skip it and you are reading heap profiles for an allocation that was never the problem, which is the gap the dev.to write-up puts at five minutes versus three hours ^[15].