Canonical is significantly overhauling how Ubuntu handles memory pressure, introducing a major change to Ubuntu 26.10 that redefines what the operating system targets when running low on RAM. Historically, low-memory situations on Linux desktops could sometimes result in erratic behavior, where critical session components or background services were terminated unpredictably while heavy applications remained untouched. With the upcoming release of Ubuntu 26.10, Canonical is restructuring this hierarchy to ensure that desktop applications are designated to fail first, while the essential services required to hold the entire user session together are pushed safely out of the kernel’s immediate line of fire.
At the heart of this new policy is a deliberate adjustment to the Out-Of-Memory (OOM) scores of thirty-nine vital system and desktop services. Under the updated configuration, components such as the GNOME Shell and crucial D-Bus services are assigned an OOM score of -500. By shifting these services deep into the negative range of the kernel’s priority scale, Canonical has made them far less likely candidates for termination when the system faces severe resource constraints. Instead, the kernel’s OOM killer will look toward heavier, resource-hogging applications—such as a web browser consuming the vast majority of a machine’s available memory—as the primary targets to be pruned in order to reclaim system stability.
Alongside these score adjustments, Canonical has also introduced a fundamental shift in how systemd-oomd operates on Ubuntu desktops. Previously, the systemd-oomd check carried the potential to abruptly terminate an entire user session based solely on memory pressure thresholds, overriding application-level priorities and sometimes crashing the desktop environment entirely. In Ubuntu 26.10, this aggressive behavior has been reconfigured, though the modification comes with the operational caveat that individual, resource-heavy applications can still be systematically terminated when physical memory and swap spaces are entirely exhausted. This refined policy has been officially implemented via the newly published ubuntu-settings 26.10.1 package and is already making its way into the active development archives for the 26.10 release cycle.
To understand the significance of these adjustments, it helps to examine how the Linux kernel evaluates processes under memory pressure. When a system runs critically low on memory, the kernel compiles a comprehensive list of every active process currently running in the environment. It evaluates each process based on the memory it accounts for, and then superimposes a user-space modifier value that dictates overall execution priority and survival order. This user-space number typically spans a numerical range from -1000 up to 1000. Processes positioned at the lowest end of this spectrum are effectively given immunity from the running order of termination, making it extraordinarily difficult for the kernel to select them during a memory crisis.
Historical data highlights the vulnerabilities that existed under previous configurations. An earlier bug report cited by Canonical detailed what the process list looked like on a standard Ubuntu 24.10 desktop environment. In that setup, critical components like the GNOME Shell sat at a score of 100, mirroring the baseline priority given to applications like Firefox and every individual content process spawned by the browser. Meanwhile, essential system daemons sat much lower on the scale, with core processes like dbus-daemon and systemd-oomd positioned at -900, and systemd-journald situated at -250.
The danger of this older scoring layout became acutely apparent during specific stress scenarios. In the reported incident, a logic error in custom user code triggered an uncontrolled proliferation of virtual machines, rapidly starving the host machine of available memory. Rather than targeting the runaway virtual machines or trimming heavy browser instances, the kernel’s OOM killer selected a remarkably lightweight utility application, gnome-characters, and terminated it instantly. The virtual machines, meanwhile, remained completely untouched, illustrating a mismatch between application utility and kernel selection logic during resource crunches.
However, kernel scores alone have never told the complete story of how Linux desktops manage memory shortages. The kernel is only one mechanism responsible for terminating processes on a modern desktop system; systemd-oomd operates in parallel by actively monitoring memory pressure metrics. Importantly, systemd-oomd acts much earlier than the kernel’s built-in OOM killer, and it traditionally made termination decisions without factoring in the customized user-space scores assigned to individual processes.
By default, Ubuntu ships with systemd-oomd configured to intervene on user sessions once memory pressure hits a 50 percent threshold. Because of this aggressive triggering point, the assignment of -500 scores to system services would not have been enough on its own to prevent premature session crashes. To close this gap, the ubuntu-settings patch addresses the behavior of systemd-oomd directly. The ManagedOOMMemoryPressure parameter has been switched to auto on the [email protected] profile, replacing the stricter and more disruptive "kill" setting utilized in previous releases. Internal testing conducted by Canonical demonstrated a dramatic improvement in stability under severe memory stress, noting that seven out of ten test sessions routinely collapsed without the fix, while none failed once the updated policy was active.
Developers and enthusiasts eager to evaluate this new behavior firsthand can already access the changes through the official daily development releases of Ubuntu. Canonical is actively encouraging users to put the updated memory management framework through rigorous workloads—particularly on hardware environments constrained by limited physical RAM or restricted swap configurations—to observe how effectively the system handles intense resource pressure. Anyone who encounters unexpected system behavior, such as abrupt application terminations or unprovoked session crashes during testing, is invited to submit detailed reports through Launchpad to help refine the implementation prior to the official stable release.
Leave a Reply