What is the Linux OOM Killer and why does it close processes?
Published on 2026-10-26 by frfrand
How Linux reacts when memory runs out, what the OOM Killer does, and how to diagnose an app that disappears.
The OOM Killer is a Linux kernel mechanism that can terminate processes when the system cannot meet certain memory needs. OOM stands for out of memory. It is not that Linux closes programs just because: it attempts to recover capacity in a critical situation.
A simple way to understand it
Imagine a restaurant without space to attend to incoming orders. If no one frees a table, the manager must make an uncomfortable decision to avoid everything getting blocked. On a server, running out of memory can leave essential processes unresponsive.
How it works in practice?
Linux manages physical memory, caches, and mechanisms such as swap. When memory recovery is not enough, it can trigger OOM actions. In environments with cgroups there are also memory limits per group or container: a process can suffer a local OOM even though the entire host still has memory available.
What it does not solve and its limits
Not all processes closed with code 137 were necessarily victims of the OOM Killer: that code is usually related to SIGKILL and there are other causes. It is not enough to look at a RAM spike either. You have to review kernel messages, container limits, swap usage, and recent changes. Increasing memory can provide margin, but it does not fix a memory leak.
How to apply it and check it without surprises
When an application disappears, look for kernel and system logs around the time of the incident. Analyze per-process consumption and its limits; review worker size, concurrency, and queries that load huge amounts of data. Then test the fix under reproducible load, without forcing endless automatic restarts.
How it appears in ArduMaker
On an ArduMaker VPS, memory limits and service load such as PostgreSQL, Redis, or workers condition stability. Monitoring memory and logs helps distinguish a process terminated by OOM from a deployment failure.
The case of a build failing with code 137
A frontend may compile perfectly on a laptop and fail when building inside a small VPS. Build tools can consume a lot of memory during short periods. If the environment kills the process with SIGKILL, first look for OOM signs and check real limits; do not automatically blame the package manager or the framework.
Is more swap enough?
Swap can provide margin in some loads, but it is slower than RAM and does not turn a small machine into a big one. You can reduce build concurrency, separate processes, or build artifacts in another environment before deploying. The right solution depends on measuring what consumes memory and when.
To remember
The OOM Killer is a Linux kernel mechanism that can terminate processes when the system cannot meet certain memory needs. Understanding when it applies, how it fails, and what data to review is more useful than memorizing isolated commands.
To learn more: Linux kernel documentation: OOM.