Ubuntu 26.10 changes how the system choose which processes are killed when memory runs low, making a rogue browser tab is less likely to punt you back to the login screen.
When your system runs out of memory, the kernel’s out-of-memory (OOM) killer kicks in, terminating processes to recover some.
The issue is that doesn’t always kill the right things.
By default, many apps and critical desktop services share the same priority score. When the OOM killer is choosing its victim target, it looks at their OOM scores, not “what’s using the most memory”.
Firefox and GNOME Shell, for example, share the same priority status. If memory pressure increases, the OOM killer may decide to terminate GNOME Shell to free up memory rather than the the process causing runaway memory requirements.
I regularly encounter this myself in Ubuntu VMs if I try to do too many things (with too many Firefox tabs open): rather than OOM nuking an app, it kills GNOME Shell instead – but I’d much rather a tab crash than my entire desktop session.
Ubuntu 26.10 makes changes to mitigate this.
Canonical’s Jean Baptiste Lallement says “the goal is simply to preserve the desktop session where possible” by terminating apps before core session services. To do this, it’s lowered the OOM scores for desktop processes so they’re less likely to be nixed.
Ubuntu 26.10 also stops systemd-oomd being able to kill user sessions as it doesn’t use the same OOM priority scores as the kernel, and important desktop services could still be nixed based on memory pressure requirements.
These changes will improve how Ubuntu copes when memory runs out, but Lallement calls it “a first step” that “does not make Ubuntu immune to OOM conditions”. More granular OOM policies for desktop services and apps are planned.
Ubuntu 26.10 is released on Thursday 15 October, 2026, but if you plan to test drive the beta that’s due on Thursday 24 September, these changes will be there – not that you’ll notice them, hopefully!
I believe there were similar services at least a decade ago, some configurable some not, but the idea isn’t new and it’s weird that they didn’t bother with adding this earlier.
Yeah OOM behavior seems like it’s been a weak point for way too long. IDK how early OOM killer isn’t standard for desktop distros.
IDK how early OOM killer isn’t standard for desktop distros.
I’d wager it’s because randomly killing processes can create data loss, that makes it a dangerous behavior to default to.
I’d rather a program crash than lock up my computer while it’s fighting with 19 bytes of free swap space lol
I’ve got auto save and git anyways. Bonus points if I can tell it to just always kill the web browser before anything else.
If I’m falling below 100MB free, I don’t think it’s likely that my task will complete perfectly, the memory usage isn’t just going to coincidentally fit perfectly like a glove. Might as well kill stuff in advance to save me the pain. Or suspend processes and pop up a dialog. IDK anything is better than the computer locking up for a long time. A really frustrating issue that never happened on Windows since SSDs.
OOM in general isn’t random every process has a score which changes it’s priority to kernel OOM killer, earlyoom in particular can be configured not to kill processes or kill specific processes. Which can be done by the distro maintainers.
I mean setting the OOM killer not to crash your desktop is a good start (which is what ubuntu is doing), but beyond that there’s not much you can do because there’s no such thing as a safe process to kill.
Obviously there are, in less desktopy environment we’ve set the oom-score for the running app itself to high so it will be killed first and will be restarted automatically, on desktopyou can easily kill browser with almost 100% surety that you’ve killed the memory hog. Problem with kernel OOM on desktop is in the condition where it will trigger, most users will find system unusable long before it will trigger (unless they have enough swap and everything configured correctly).
I hope some of these changes are considered in other projects. Me on Debian, I’ve had Konsole killed a handful of times when a process running under one of the bash shells in tabs exceeded available memory. I would have expected the oom killer to target the most child processes, not a parent doing other things too.
Why kill anything to begin with? IMO better to error or slow down.
Because sometimes you don’t have a choice, you can only do what you suggest it there’s enough free swap to do so. Otherwise you have to kill processes.
