Why Your Linux PC Freezes When RAM Runs Out (and the 2-Minute earlyoom Fix That Prevents Hard Lockups)

Last updated: November 10, 2026 · 4-minute read

If you use Linux as your daily development workstation, you know this nightmare scenario all too well:

You start compiling a large codebase with cargo build, spin up multiple heavy Docker containers, or train a small ML model in Python. Suddenly, your music stutters. Then the mouse cursor stops moving. Your keyboard caps-lock light won't even toggle. The hard drive LED blinks frantically.

Your entire operating system is completely frozen. You wait two, five, ten minutes hoping the Linux kernel recovers. It doesn't. Eventually, you resign yourself to holding down the physical power button on your machine, rebooting, and losing all your unsaved terminal work and open files.

Why does an operating system renowned for enterprise stability choke so violently when memory runs out? And why doesn't Linux's built-in Out-Of-Memory (OOM) killer save you?

Here is the technical reason your Linux desktop freezes under memory pressure, and how a tiny 2-minute daemon called earlyoom permanently fixes the problem.

The Swap Thrashing Trap

Most developers assume that when RAM hits 100%, the Linux kernel immediately invokes its built-in OOM killer to terminate the rogue process.

In reality, the kernel's built-in OOM killer is designed as an absolute last resort of catastrophic failure. It only triggers when the kernel literally cannot allocate a single 4KB memory page—a condition called page allocation failure.

Long before that happens, your system enters a death spiral known as swap thrashing:

1. Evicting the Page Cache: When physical RAM fills up, the Linux kernel starts reclaiming memory by evicting cached executables, shared libraries, and filesystem buffers. 2. Desperate Swapping: The kernel tries to page anonymous memory out to your swap space (whether a swap file, partition, or zram). 3. I/O Gridlock: Every time your desktop environment (GNOME, KDE, or X11/Wayland), terminal, or mouse driver tries to execute a basic instruction, its code is no longer in RAM. The kernel must pause the entire CPU thread, issue a disk read to pull the code back from swap, execute two instructions, and immediately swap it back out to make room for another process. 4. The Complete Lockup: Because disks (even fast NVMe SSDs) are orders of magnitude slower than system RAM, the kernel spends nearly all of its time waiting on I/O. The system becomes unresponsive, but because the kernel is technically still making micro-progress, the built-in OOM killer refuses to step in.

User-Space Intervention with earlyoom

Instead of waiting for total system paralysis, earlyoom runs as a lightweight user-space background daemon.

It constantly checks /proc/meminfo (every 100 milliseconds) for two metrics: Available Free RAM Available Free Swap

By default, if both free RAM and free swap drop below 10%, earlyoom steps in before disk thrashing begins. It identifies the single biggest memory consumer using /proc//oomscore and sends it SIGTERM. If memory falls further — to half the threshold by default — it sends SIGKILL instead.

Your browser tab or out-of-control build process closes cleanly, but your terminal, IDE, mouse, and system remain completely alive and responsive.

Step 1: Install earlyoom in 30 Seconds

earlyoom is packaged in the official repositories of almost every major Linux distribution:

# On Fedora / RHEL sudo dnf install earlyoom

# On Arch Linux / Manjaro sudo pacman -S earlyoom

Step 2: Enable and Start the Service

Once installed, enable the service so it automatically protects your system on boot:

Verify that the daemon is actively running:

You should see an active status showing its current memory monitoring loop (representative output — your PID and figures will differ):

Notice that earlyoom uses less than 1.5MB of RAM and virtually zero CPU cycles while idling in the background.

Step 3: Customize Thresholds and Protected Apps

On modern developer machines, you might want more aggressive thresholds or want to prevent earlyoom from terminating critical processes like your code editor.

Open the configuration file:

You can customize the EARLYOOMARGS variable:

Key configuration flags: -m 7: Triggers action when available RAM drops below 7%. -s 5: Triggers action when available swap drops below 5%. --avoid: Regex of process names to avoid killing if possible. --prefer: Regex of known memory hogs to target first (e.g., browser renderer processes or runaway Node scripts).

Restart the service to apply changes:

Desktop Notifications