Ubuntu 26.10 OOM Changes: Protecting the Linux Desktop

Ubuntu 26.10 OOM Changes: Protecting the Linux Desktop

When Linux runs out of memory, the kernel’s Out-Of-Memory (OOM) Killer must terminate processes to recover enough RAM and keep the system alive. The critical question is not whether something gets killed, but which process gets sacrificed first.

On Ubuntu desktops, that decision has sometimes produced an especially painful result: instead of terminating the memory-hungry application, the system can lose critical desktop components such as GNOME Shell or D-Bus. The result may be a broken graphical session, a return to the login screen, and potentially lost unsaved work.

Canonical’s desktop team is changing that behavior in Ubuntu 26.10 by adjusting OOM priorities for critical desktop services and changing how systemd-oomd handles user sessions.

Here is what changes, what the update does not solve, and how users can prepare for memory pressure today.

🧠 Why the Linux OOM Killer Can Take Down the Desktop

#

When physical RAM and available swap are exhausted, Linux needs to reclaim memory quickly. The kernel’s OOM Killer selects processes according to several factors, including the oom_score_adj value assigned to each process.

The range runs from -1000 to 1000:

• -1000 provides the strongest protection from the OOM Killer.
• 0 represents the default adjustment.
• Positive values make a process a more attractive OOM target.
• 1000 makes a process highly vulnerable to being selected.

The problem in a desktop environment is that not all processes are equally replaceable.

A browser tab, text editor, or background application can usually be restarted. GNOME Shell and D-Bus, however, are deeply involved in maintaining the graphical desktop session.

Canonical desktop developer Jean-Baptiste Lallement referenced Launchpad Bug #2089800 in a Canonical Discourse discussion concerning unreasonable OOMScoreAdjust values on Ubuntu Desktop.

The practical failure mode is straightforward:

A memory-hungry application can survive while a critical desktop service is terminated.

If GNOME Shell or another essential session component disappears, the user may lose the entire graphical environment even though the underlying operating system is still running.

🛡️ What Changes in Ubuntu 26.10

#

Ubuntu 26.10 changes the OOM policy around desktop services in several important ways.

Protecting critical desktop services

#

Critical components such as GNOME Shell and D-Bus receive lower OOM scores, making them less likely to become victims when the kernel needs to reclaim memory.

The goal is not to make these processes impossible to terminate. Instead, Ubuntu is changing their relative priority so that less critical applications become targets first.

Leaving ordinary applications more exposed

#

Standard applications such as browsers, editors, and background services retain comparatively higher OOM scores.

This creates a more practical failure mode during severe memory exhaustion:

Lose an application first rather than lose the entire desktop session.

An application can generally be reopened. A graphical session crash can interrupt every application running on the desktop simultaneously.

Changing systemd-oomd behavior

#

The other major component is systemd-oomd, a userspace service that monitors memory pressure and can terminate processes or groups of processes before the kernel reaches a full OOM condition.

This creates a second layer of memory-management decisions.

The kernel’s OOM Killer considers process-level OOM scoring, while systemd-oomd primarily responds to memory pressure. Consequently, lowering the OOM score of a desktop service does not automatically protect it from every userspace memory-pressure policy.

Ubuntu 26.10 is therefore changing the handling of automatic user-session termination by systemd-oomd, with the goal of avoiding a situation where protected desktop services are still terminated by a separate mechanism.

In practical terms, Ubuntu is moving toward a clearer priority:

When memory pressure becomes critical, terminate replaceable applications before sacrificing the desktop session.

The relevant changes are being introduced through the Ubuntu desktop configuration, including the ubuntu-settings package, in the Ubuntu 26.10 development cycle.

⚠️ What This Fix Does Not Solve

#

The changes should not be interpreted as an OOM-proofing mechanism.

Applications can still be terminated

#

If the system genuinely runs out of reclaimable memory, Linux still needs to free memory.

Ubuntu 26.10 does not eliminate the OOM Killer and does not guarantee that applications will remain alive during extreme memory exhaustion.

More RAM is still more RAM

#

Changing OOM priorities cannot make a 4GB system behave like a 16GB system.

Memory pressure can still cause:

• Application termination
• Heavy swapping
• Desktop slowdowns
• Increased latency
• Temporary freezes
• Lost application state

The improvement is primarily about which failure happens first.

A browser process disappearing may be recoverable. Losing the entire graphical session while working on an unsaved document can be considerably more disruptive.

Future tuning is still possible

#

Canonical has indicated that the current work is an initial step toward refining OOM priorities for different desktop services and application categories.

Testing on systems with limited RAM and swap can therefore help identify cases where the new priorities still produce undesirable behavior.

🔧 Four Ways to Reduce OOM Problems Today

#

Ubuntu 26.10 is not required for users to start improving memory-pressure behavior.

1. Check systemd-oomd

#

First, check whether the userspace OOM daemon is active:

systemctl status systemd-oomd

You can also inspect the kernel’s current OOM scores:

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

The two values provide different information:

• oom_score is the process’s current OOM score.
• oom_score_adj is the adjustment applied by the system or administrator.
• Higher scores generally make a process a more attractive OOM target.
• Negative oom_score_adj values increase protection.

This is useful when diagnosing why a particular process was selected.

2. Enable zram

#

For systems with limited RAM, zram can provide compressed swap space directly in memory.

Instead of immediately writing swapped pages to a physical disk, zram compresses them and stores them in RAM. This consumes some CPU and memory resources, but can reduce pressure on systems where conventional swap is relatively slow.

Check the current swap configuration:

swapon --show

If /dev/zram0 is not present, one possible configuration using systemd-zram-generator is:

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 systemd-zram-setup@zram0.service

Here:

• zram-size = ram / 2 configures a compressed swap device with a size equal to half the system’s physical RAM.
• compression-algorithm = zstd selects the compression algorithm.
• swap-priority = 100 gives the zram swap device a high priority relative to lower-priority swap devices.

Verify the result with:

zramctl
swapon --show

Important zram considerations

#

zram is not a replacement for every type of swap configuration.

For example, systems that require hibernation generally need persistent disk-backed swap because the contents of RAM must survive a complete power-off cycle.

Also avoid stacking multiple compression mechanisms without understanding their interaction. Running both zram and zswap can introduce additional CPU overhead without necessarily providing a useful benefit for a particular workload.

3. Adjust OOM protection for systemd services

#

Administrators can manually change the OOM adjustment for individual services.

For example:

sudo systemctl edit foo.service

Then add:

[Service]
OOMScoreAdjust=-500

The adjustment ranges from -1000 to 1000.

• Negative values provide greater protection.
• Positive values make a process easier for the OOM Killer to select.
• -1000 provides the strongest possible OOM protection.

For an individual application launched through systemd-run, you can instead assign a positive value:

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

This makes the Firefox process a highly preferred OOM target compared with processes that have lower adjustments.

Use these settings carefully. Over-protecting too many processes can make the OOM situation worse because the kernel has fewer viable processes available to terminate.

4. Save important work frequently

#

No OOM policy can guarantee that application data will survive a severe memory failure.

Autosave, frequent manual saves, browser session restoration, and application-level recovery mechanisms remain useful safeguards.

🧪 How to Test Ubuntu 26.10 OOM Behavior

#

A controlled memory-pressure test can help determine whether the desktop remains usable when RAM becomes heavily constrained.

On an appropriate test machine, install stress-ng:

sudo apt install stress-ng

Then generate memory pressure:

stress-ng --vm 2 --vm-bytes 90% --timeout 120s

Do not run aggressive memory-stress tests on production systems containing unsaved work. The purpose is to reproduce memory-pressure behavior in a controlled environment.

Comparison Matrix

#

The key point is that the update changes termination priority, not the fundamental behavior of Linux memory exhaustion.

📊 Why OOM Policy Matters More on Desktop Linux

#

Server workloads can often be designed around predictable process supervision and service restart policies. Desktop systems are different.

A modern Linux desktop may simultaneously run:

• A browser with dozens of tabs
• IDEs and development tools
• Containers and virtual machines
• Electron applications
• Database services
• Background synchronization tools
• Media applications
• GNOME Shell and other desktop services

When RAM becomes scarce, terminating one application is often recoverable. Terminating the component responsible for the graphical session can affect everything at once.

That makes OOM scoring particularly important for desktop distributions.

The ideal policy is therefore not simply to prevent process termination. It is to make the least disruptive process the most likely target.

🧩 Ubuntu 26.10’s Practical OOM Strategy

#

Ubuntu 26.10 does not fundamentally rewrite Linux memory management. Instead, it adjusts the priorities surrounding desktop-critical processes.

The overall strategy can be summarized as:

1. Protect essential desktop services.
2. Allow ordinary applications to remain more expendable.
3. Avoid conflicting userspace behavior that can terminate protected desktop sessions.
4. Give users better tools to manage memory pressure through mechanisms such as zram and OOM scoring.

That approach addresses a specific but highly visible failure mode: a system with insufficient memory should ideally lose an application before it loses the interface through which the user controls the system.

For users running low-memory hardware, the combination of sensible swap configuration, zram, appropriate OOM priorities, and frequent saves can provide additional resilience while Ubuntu’s desktop memory-management policy continues to evolve.