Ubuntu 26.10 Rewrites OOM Killer Rules: Protect Desktop, Kill Apps First

01 The Moment That Spikes Your Blood Pressure

When memory runs low, the desktop freezes first. The mouse moves but clicks do nothing. Seconds later the graphical interface vanishes, dropping you back to the login screen. Any unsaved work is gone.

The culprit is the kernel's OOM Killer. OOM stands for Out Of Memory. After physical memory and swap are exhausted, the kernel must kill processes to free space, otherwise the whole system crashes.

The real problem isn't whether to kill, but which process to kill .

The kernel uses a score called oom_score_adj (range -1000 to 1000). Higher scores die first. This mechanism reserves protection for critical processes, but on the desktop it often miscalculates.

Canonical desktop team member Jean-Baptiste Lallement cited bug 2089800 : "Ubuntu desktop unstable under memory pressure due to unreasonable OOMScoreAdjust values."

In plain terms: the memory-hogging browser stays alive while GNOME Shell and D-Bus — the processes that keep the desktop running — get killed first. When those two die, the desktop collapses instantly.

02 Three Changes in 26.10

This update brings "who dies first" back under predictable rules. Three changes:

Lower scores for critical desktop services. GNOME Shell, D-Bus, and other session-critical services receive reduced OOM scores, making them less likely to be selected.

Keep regular applications at high scores. Browsers, editors, background services retain higher default scores. When memory is truly exhausted, they go first. The logic is simple: losing an app lets you keep working; losing the desktop leaves you with nothing.

Disable systemd-oomd for user sessions. This is the most critical and easily overlooked change. systemd-oomd is a user-space memory guardian with its own decision logic (memory pressure) separate from the kernel's OOM score. Even with lowered scores, systemd-oomd could still kill GNOME Shell based on pressure alone. Two referees blowing different whistles made protection ineffective. Ubuntu simply turns off this layer, leaving only the kernel's rules.

Together: When memory explodes, sacrifice applications first, keep the desktop alive.

The changes live in the ubuntu-settings package and are already active in the current development release "Stonking Stingray".

03 What It Does NOT Solve

Let's be clear to avoid false hopes.

It will not stop Ubuntu from killing processes altogether. When memory is truly exhausted, apps will still be killed.

It will not make a 4 GB machine feel like 16 GB.

It solves exactly one concrete problem: under memory pressure you lose a restartable application instead of the entire desktop. Anyone who has been OOM-killed knows the difference — browser tabs can be restored; unsaved work on the desktop is gone forever.

Canonical notes this is only a first step; future versions will refine priorities further, treating different service and application types separately. They explicitly invite testing, especially on low-memory, low-swap machines, and ask users to report unexpected kills on Launchpad.

04 Four Things You Can Do Right Now

1. Check systemd-oomd Status

systemctl status systemd-oomd

If it shows active, the user-space mechanism is still running — the second referee is still on the field.

Quickly inspect the kernel's current scores:

ps -eo pid,comm,oom_score,oom_score_adj --sort=-oom_score | head -15

oom_score

is the kernel's real-time computed final score; oom_score_adj is the bias added by you or the system. The highest-scoring processes are the first to be sacrificed.

2. Enable zram

This is the single most effective step for memory-constrained machines. zram creates a compressed block device in RAM to use as swap; swapped pages never leave memory, making it far faster than disk swap.

Check if you already have it: swapon --show If /dev/zram0 is absent, install and configure:

sudo apt install systemd-zram-generator
sudo tee /etc/systemd/zram-generator.conf > /dev/null << 'EOF'
[zram0]
zram-size = ram / 2
compression-algorithm = zstd
swap-priority = 100
EOF
sudo systemctl daemon-reload
sudo systemctl start [email protected]

zram-size = ram / 2

allocates half of physical RAM. It's not pre-allocated; memory is only consumed when pages are actually written, so over-provisioning is harmless. swap-priority = 100 ensures zram is used before any disk swap.

Verify:

zramctl
swapon --show

zramctl

shows compressed vs. original sizes; typical compression ratios are 2:1 to 3:1.

Two caveats:

zram cannot hibernate — hibernation requires writing memory to disk, but zram vanishes on power loss. If you need hibernate, keep a disk swap partition at least as large as RAM.

Do not enable zswap simultaneously — that compresses twice, wasting CPU.

3. Manually Lower Scores for Critical Processes

No need to wait for 26.10; you can protect specific services now. For a systemd-managed service: sudo systemctl edit foo.service Add:

[Service]
OOMScoreAdjust=-500

Negative values protect; positive values increase kill likelihood. Range is -1000 to 1000.

For regular applications, set a high score at launch:

systemd-run --scope -p OOMScoreAdjust=1000 firefox

This makes Firefox the first candidate when memory runs out.

4. Build a Habit of Saving Frequently

It sounds trivial. But after losing an unsaved document to an OOM kill once, you'll understand it's not trivial.

05 How to Verify the Fix When 26.10 Arrives

Here's a reproducible self-test. Don't just take anyone's word.

On an 8 GB machine, open dozens of browser tabs, then run a memory-hogging task to push usage near the limit:

sudo apt install stress-ng
stress-ng --vm 2 --vm-bytes 90% --timeout 120s

Compare the behavior before and after the upgrade:

First killed: 26.04: GNOME Shell / D-Bus; 26.10: Browser, background services

Desktop outcome: 26.04: Entire desktop disappears, returns to login; 26.10: Applications close, desktop stays up

Your loss: 26.04: Unsaved work; 26.10: A restartable browser tab

If the desktop survives on 26.10, the change is genuinely effective. If it still crashes, file a bug on Launchpad — that's exactly the feedback Canonical wants.

06 My Take

Canonical is fixing a years-old pain point. They didn't overhaul the kernel OOM mechanism, nor did they promise zero lag. They simply straightened out the survival priority of desktop services. Small, targeted fixes that solve real pain inspire more confidence than flashy launch-event features.

One context worth noting: memory prices have been rising for years, and many users won't be upgrading RAM soon. Making software use existing memory more precisely is the most pragmatic response in this environment.

On October 15 I'll test this on an 8 GB machine using the method above and report back whether this lifeline actually works.

What's the worst thing you've lost to a Linux OOM kill?