Ubuntu 26.10 Stops the OOM Killer Taking Down GNOME Shell, and Disables systemd-oomd's Session Kill

Ubuntu 26.10 Stops the OOM Killer Taking Down GNOME Shell, and Disables systemd-oomd's Session Kill

Ubuntu 26.10 changes what gets killed when the desktop runs out of memory. The problem it fixes is a familiar one: the OOM killer takes out GNOME Shell or D-Bus, and the whole session dies instead of one greedy application.

Jean Baptiste Lallement of Canonical’s Ubuntu Desktop Team set out the new policy:

“The new policy gives critical desktop services more protection:

  • Critical desktop services now use a lower OOM score, making them less likely to be selected by the kernel OOM killer.
  • Applications and background services keep a higher default score, so they remain more likely to be terminated first.
  • The automatic systemd-oomd memory-pressure kill for the whole user session is disabled. systemd-oomd does not use the same OOM priority scores as the kernel. It could then terminate a critical desktop service based on memory pressure alone.”

Why the desktop was dying instead of the browser

The kernel OOM killer picks a victim by score, and the score is driven heavily by how much memory a process is using. That heuristic is reasonable for a server and wrong for a desktop.

GNOME Shell is a large process. It holds the compositor, the window manager and the shell UI. Under memory pressure it looks like an excellent candidate by size, and killing it is catastrophic by consequence: every window disappears, because the thing drawing them is gone.

The browser tab that actually caused the pressure might be a smaller individual process and survive the cull.

Score is not the same as expendability, and Ubuntu is now encoding that difference explicitly.

The systemd-oomd part is the sharper change

The second item is more than a tuning adjustment.

systemd-oomd kills things based on pressure stall information, meaning how much time processes spend waiting on memory, rather than on the kernel’s OOM scores. Two systems, two notions of what to kill, and no agreement between them.

The result was that carefully setting a low OOM score on GNOME Shell bought nothing, because systemd-oomd was not reading that score. It could decide the user session was under pressure and terminate something critical regardless.

Disabling the automatic session-wide memory-pressure kill leaves the kernel’s OOM killer, which does honour the scores, as the mechanism of last resort. One policy instead of two competing ones.

The tradeoff is real and worth stating: systemd-oomd exists because the kernel OOM killer is slow to act. A system can thrash for a long time before the kernel declares an emergency, and during that time the desktop is unusable even though nothing has been killed. Removing the pressure-based kill may mean more time spent in that unpleasant middle state.

Canonical is honest about the limits

“Of course, this does not prevent applications from being terminated when the system runs out of memory, and it does not make Ubuntu immune to OOM conditions. The goal is simply to preserve the desktop session where possible, and terminate applications before the services needed to keep that session running.”

That is the right claim to make. Losing a browser and keeping your session is a bad minute. Losing your session is a lost afternoon.

A different answer to the same problem

GNOME OS is attacking this from the other end by enabling zswap by default, which reduces how often the system reaches OOM at all by compressing pages in RAM rather than evicting them.

The two are complementary rather than competing. Zswap postpones the crisis. OOM scoring decides who dies when it arrives anyway.

Checking and adjusting your own

# OOM score for a running process (higher means killed sooner)
cat /proc/$(pidof gnome-shell)/oom_score
cat /proc/$(pidof gnome-shell)/oom_score_adj

# what systemd-oomd is doing
systemctl status systemd-oomd
oomctl

# protect a service in its unit file
# ManagedOOMPreference=avoid
# OOMScoreAdjust=-500

OOMScoreAdjust in a unit file is the supported way to express the same preference for your own services, and our systemd service guide covers where it goes. For containers the equivalent lever is cgroup memory limits, which bound the damage before the system-wide killer is involved at all.

Further OOM work is expected after 26.10 ships on October 15.

Background reading

Explainers for the concepts behind this story.