Why Does Your Linux System Suddenly Freeze?
Opening 30 Chrome tabs, running 5 Docker containers, typing code in VS Code – and boom, the mouse cursor starts stuttering before a complete freeze. If you use Fedora as your primary dev machine, you’ve likely encountered this at least once. I’ve used Fedora for over 2 years and love the package update speed, but RAM management remains a challenge without proper tuning.
Previously, the Linux Kernel used the OOM Killer to solve this. Unfortunately, it often acted too late. By the time the Kernel realized the system was out of RAM, the machine was usually in a “thrashing” state. At this point, the CPU is busy swapping data between RAM and Swap constantly. The result is a paralyzed system where you can’t perform any actions.
systemd-oomd was created to change the game and has been the default in Fedora since version 34. Instead of waiting for RAM to run out, it monitors Pressure Stall Information (PSI). PSI indicates how long applications must wait for resources (CPU, RAM, I/O). If the wait time exceeds a safe threshold, systemd-oomd proactively intervenes before the system locks up.
Checking systemd-oomd Status
Even though Fedora comes with this tool pre-installed, you should still check if it’s running correctly, especially on Server editions. Open your terminal and run:
systemctl status systemd-oomdIf you see the line active (running), your system is protected. To see details of the resource groups (cgroups) being monitored, use the command:
oomctlThis command lists the Control Groups and current memory pressure levels. A major plus of systemd-oomd is its ability to manage by application group. It won’t just kill a single isolated process but will handle the entire related cluster to free up RAM effectively.
Optimal Configuration for Developers
The main configuration file is located at /etc/systemd/oomd.conf. Fedora’s defaults are quite good, but if you frequently run heavy tasks, consider making adjustments.
sudo nano /etc/systemd/oomd.confPay attention to these three key parameters:
- SwapUsedLimitPercent: Default is 90%. If swap reaches 90%, the system takes action. For high-speed NVMe SSDs, you can leave it as is. If using an old HDD, lower it to 80% to avoid lag.
- DefaultMemoryPressureLimitPercent: Memory pressure limit (default 60%). If an app causes the system to delay more than 60% of the time due to lack of RAM, it gets put on the “handling” list.
- DefaultMemoryPressureDurationSec: How long the pressure must persist before triggering (default 20 seconds).
After editing, restart the service:
sudo systemctl restart systemd-oomdHow to Protect Important Applications
Sometimes you’re rendering a video or running a heavy script and don’t want systemd-oomd to close them unexpectedly. We can configure individual User Slices to relax the limits.
To protect your current session, create an override file with the command:
systemctl edit user.sliceAdd the following content to the file:
[Slice]
ManagedOOMMemoryPressure=auto
ManagedOOMMemoryPressureLimit=80%Raising the limit to 80% gives applications more “breathing room” before being flagged as harmful to the system.
Monitoring and Real-world Testing
How do you know how many times systemd-oomd has saved your machine? You can check the system logs. This is how I usually debug why Chrome suddenly closed this morning:
journalctl -u systemd-oomdIf an application is stopped, the log will clearly show: “Killed /user.slice/… due to memory pressure”.
To perform a stress test, you can use this small script to force the system to run out of RAM. Note: Save all your work before trying this.
# Create a 16GB virtual RAM partition and write data to exhaust memory
sudo mount -t tmpfs -o size=16G tmpfs /mnt
dd if=/dev/zero of=/mnt/test_file bs=1M count=15000If working correctly, systemd-oomd will kill the dd command as soon as the system starts showing signs of sluggishness.
Real-world Experience on Fedora
Whether your machine has 32GB of RAM or more, never disable systemd-oomd completely. Instead, combine it with zRAM. Fedora uses zRAM to compress data directly in RAM instead of writing to the disk. This combination keeps the system extremely responsive even under heavy load.
If you find this tool too “aggressive”, try increasing DefaultMemoryPressureDurationSec to 30 or 40 seconds. This gives the system more time to naturally free up memory before taking drastic measures.
I hope this tip helps make your Fedora experience more stable. From now on, you won’t have to hit the power button to restart every time you accidentally open too many tabs.
