David Herron
Tags: Ubuntu »»»»
The user environment on my Ubuntu laptop kept crashing, and I couldn't figure out why or find a solution. Turns out that high memory usage, coupled with an Ubuntu subsystem for reining in "memory pressure", was addressing the problem by killing every process in my login session. The cure is relatively simple.
My main work environment, for fairly heavy duty software development, is a 10 year old Dell Latitude E7450 laptop. It has a 5th generation Core i7 CPU, maxed out at 16GB of memory and a 1 terabyte mSATA drive. It is running Ubuntu 24.04.
For the time period it was made, this laptop was high end, just like the 13 year old mid-2012 Mac Book Pro sitting next to it. Today, both are easily swamped.
Generally the performance is good, but every so often the system feels overloaded and then the user environment crashes and wipes everything out. “Feels overloaded” means the fans start running full, the mouse might stop responding well, or might freeze completely. Usually the user environment crash (if it happens) will occur after 2-3 minutes of the system being overloaded. Sometimes it gets into the overloaded state, then recovers without crashing.
The operating system does not crash - simply all user processes and the desktop environment. I end up at the GNOME Login prompt, rather than watching the machine reboot.
I shouldn't be surprised. I regularly have multiple web browser (Chrome) windows open, and perhaps a hundred browser tabs active at a time, along with Visual Studio Code (several windows), Obsidian (several windows), multiple terminal tabs, and multiple file system browser windows, all open at the same time. I might even have background processes, like MongoDB, or whatever server-side app I'm working on at a given time.
That's a lot of memory and CPU power being requested out of this old laptop.
No wonder this system has problems.
The OOM Killer on Linux
One thing my occasional searches for clues turned up was the OOM Killer, and that it must be configured to kill off the entire user session. But that clue wasn't enough to give an answer, until I asked Perplexity.
The OOM Killer (Out of Memory Killer) is a "safety valve" mechanism built into the Linux kernel. Its goal is to prevent the system from freezing or crashing completely when it runs out of physical RAM. It is part of the Linux kernel, and is therefore available on almost every Linux distro.
It is triggered when a system runs out of free memory and cannot swap data to the hard drive.
In theory, it selects one or two processes to terminate, in order to free up memory. In practice, ...?
It is supposed to compute an oom_score for all processes. This score includes weighting for total resident set size (physical RAM consumed by the process), CPU usage, and whether it is a root process.
These commands will show recent process terminations by the OOM Killer:
sudo dmesg -T | grep -i 'killed process'
journalctl -k | grep -i 'oom'
For example:
Feb 02 18:28:34 davidpc kernel: \
Out of memory: Killed process 266992 (chrome) total-vm:1460015524kB, \
anon-rss:469584kB, file-rss:128kB, shmem-rss:10044kB, \
UID:1000 pgtables:3480kB oom_score_adj:300
How heavy usage contributes to out of memory situations
Each process consumes some memory. Each open tab in Chrome consumes at least one process.
When memory consumption gets close to the physical RAM, the operating system needs to take steps to keep the whole system going.
The first step is for the OS to start "swapping". Swapping is when the OS writes some memory contents to disk, in a "swapfile". It then removes that memory from physical memory by making those memory pages available for other processes.
This is called "paging out", because pages of memory are written out to disk.
When a process needs to access its memory that's been paged out, the operating system has to read the pages from the swapfile back into physical memory.
This is called "paging in", because pages of memory are read from disk.
The process of paging in, and paging out, will obviously take some time. It doesn't matter how fast the disk is, it is slower than physical RAM.
Heavy swapping means:
- CPU in the kernel doing page reclaims
- High I/O due to swap
- GUI input (mouse/keyboard) lagging or freezing for seconds at a time
Another term for heavy swapping is "thrashing", meaning the system spends more and more time paging in/out than it spends on doing actual work.
This is when the OOM Killer starts looking for processes to kill. It might end up killing the entire user login session.
Curing memory pressure, avoiding thrashing
The first step to cure memory pressure is to do what I used to do - which is install a tab suspender extension in Chrome. I used to use The Great Suspender but it was removed from the Chrome extension store. Tab suspenders help by noticing a browser tab that's been idle for "long enough". It records everything required to restart the tab, then kills the tab without closing the tab, replacing it with a placeholder describing how to reinstate the tab.
Another step is to check for BIOS updates. The manufacturer may have worked out ways to more efficiently cool the system.
Another step is to refresh the thermal paste in the CPU.
You might keep a terminal open with htop so you can inspect what's happening and notice high computation and/or memory use.
These commands directly let you see current memory use, and swap use.
free -h
swapon --show
cat /proc/swaps
For example:
$ swapon --show
NAME TYPE SIZE USED PRIO
/swap.img file 8G 705.1M -2
This shows a system that's lightly used, and has plenty of available swap space.
But, this is my laptop:
$ swapon --show
NAME TYPE SIZE USED PRIO
/swapfile file 2G 2G -2
/swapfile2 file 16G 13.4G -3
/swapfile3 file 16G 0B -4
This is nearly 16GB of swap consumption, nearly the same as the physical RAM in this computer. Previously, I'd had only the 2GB /swapfile for swap. If my typical usage pattern requires 32GB (16GB physical RAM, and 16GB swap) then it's no wonder that my system would regularly run out of memory space.
Adding more swap memory
Adding more memory, then, is another solution. Fortunately this is easy peasy.
$ sudo fallocate -l 16G /swapfile3
$ sudo chmod 600 /swapfile3
$ sudo mkswap /swapfile3
Setting up swapspace version 1, size = 16 GiB (17179865088 bytes)
no label, UUID=a4d1925b-d543-4f90-986b-af2417105dec
$ sudo swapon /swapfile3
$ sudo vi /etc/fstab
# add this:
# /swapfile3 none swap sw 0 0
$ swapon --show
NAME TYPE SIZE USED PRIO
/swapfile file 2G 2G -2
/swapfile2 file 16G 7.2G -3
/swapfile3 file 16G 0B -4
It's normal, and preferred best practice, to use a disk partition for the swap area. But, as is done here, it can be a file in the filesystem. The swapon command commences swapping activity on that file. For this file to be permanently used for swapping, it must be in /etc/fstab as shown here.
Tuning swappiness with vm.swappiness
The kernel parameter vm.swappiness controls how aggressively Linux moves pages from physical RAM into swap. It takes a value between 0 and 200, with a default of 60. Lower values tell the kernel to prefer keeping data in RAM and avoid swapping; higher values make it swap more readily.
I have not experimented with this setting, but it is worth being aware of. To check the current value:
$ cat /proc/sys/vm/swappiness
60
To temporarily change it (until the next reboot):
$ sudo sysctl vm.swappiness=40
To make the change permanent, add a line to /etc/sysctl.conf or create a file in /etc/sysctl.d/:
$ echo 'vm.swappiness=40' | sudo tee /etc/sysctl.d/99-swappiness.conf
$ sudo sysctl --system
A value of 0 does not disable swapping entirely -- the kernel will still swap when free and file-backed pages drop below the zone watermarks. On a desktop system where responsiveness matters more than throughput, a value in the range of 10-40 may reduce thrashing compared to the default of 60.
Understanding systemd-oomd on Ubuntu
Starting with Ubuntu 22.04, the system ships with systemd-oomd, a user-space OOM daemon that runs alongside the kernel's built-in OOM Killer. This is likely what is responsible for killing the entire user session rather than individual processes.
While the kernel OOM Killer picks off individual processes based on oom_score, systemd-oomd monitors memory pressure at the cgroup level. When a cgroup (such as the one containing your entire desktop session) exceeds its memory pressure thresholds, systemd-oomd can kill the whole cgroup at once -- which is exactly the behavior I was seeing.
I have not tried adjusting systemd-oomd, but here are the key commands for inspecting it:
$ systemctl status systemd-oomd
$ oomctl
$ journalctl -u systemd-oomd
The configuration file is at /etc/systemd/oomd.conf, where you can adjust thresholds like SwapUsedLimit and DefaultMemoryPressureLimit. You can also override the behavior for specific systemd units by setting ManagedOOMSwap= and ManagedOOMMemoryPressure= in their unit files.
If adding swap space and reducing browser memory usage are not enough, tuning or disabling systemd-oomd is the next step to investigate.
Browser tab suspenders
The Great Suspender used to be a great application. I haven't tried the following, but they look good:
-
Auto Tab Discard Auto-discards after customizable time (default 10 min); manual discard/release; preserves YouTube timestamps/forms; auto-restores on focus. Closest match: native API, lightweight, no crashes lose tabs; widely praised as top replacement.
-
-
-
Another option is to switch browsers:
Mozilla Firefox: Scales well with many tabs (~960MB baseline but efficient); native tab suspension via about:config tweaks (e.g.,
browser.tabs.unloadOnLowMemory); privacy-focused.
Conclusion
If your Ubuntu desktop keeps crashing back to the login screen, the OOM Killer is a likely culprit. When physical RAM is exhausted and swap space runs out, the kernel has no choice but to start killing processes -- and it may take your entire user session with it.
The fixes are straightforward:
- Add more swap space using swap files. If your workload regularly exceeds physical RAM, make sure you have enough swap to absorb the overflow.
- Install a browser tab suspender to reduce Chrome's memory footprint. Dozens or hundreds of open tabs can consume gigabytes of RAM that you're not actively using.
- Monitor memory and swap usage with tools like
htop,free -h, andswapon --showso you can spot trouble before a crash occurs. - Check
dmesgandjournalctlfor OOM Killer messages to confirm whether memory exhaustion is actually behind your crashes. - Tune
vm.swappinessto control how aggressively the kernel swaps. A lower value can reduce thrashing on desktop systems. - Inspect
systemd-oomdif your entire desktop session is being killed. On Ubuntu 22.04+, this user-space daemon may be the one terminating your session at the cgroup level.
An older machine with 16GB of RAM can still be a capable development workstation -- it just needs enough breathing room in swap, and some discipline around browser tab usage, to keep the OOM Killer at bay.
