I almost got LineageOS compiling on F40 KDE, and the first time the konsole window just closed. I tried it again after adding a USB 3.0 external HDD as 1TB swap, and I come back to my laptop suspended because Plasma got killed and it kicked me back to log-in. I try again, and after an hour Plasma got killed and I got kicked to a black screen and REISUB’d.
What the heck is OOM killer doing being allowed to kill off the DE, which of course also takes out everything else with it?
Is OOM killer implemented the same on all Fedora editions including GNOME? It sounds odd that it would be implemented and allowed to kill off desktop environments, and without tweaking it it implies Fedora is unstable in any event that happens to exhaust RAM. This happened even with a 1TB swap partition.
I want answers and a better understanding. Why is this allowed? I used Windows since 95 and never had Explorer killed off when OOM.
It sounds like oomd can be restricted from affecting certain processes: Changes/EnableSystemdOomd - Fedora Project Wiki?
So it sounds like it would be as-easy as having DEs on that list, but apparently this was an issue over a year ago still: Why is systemd-oomd still a thing : Fedora
This is based on assumptions, but I’m guessing people smarter than me would have put all desktop environments on an OOM killer blacklist day-one, or at least the ones with Wayland sessions. So either the blacklist isn’t working, Plasma 6 (and apparently GNOME) aren’t added to it, or DEs aren’t added at all, implying introduced instability.
I used Fedora because I trusted and liked their decisions, but I’m having a hard time with this one. I’m sure someone related to QA has seen this report or the other one above, and having DEs whitelisted makes sense to me out-the-box (it should have been done already if it was going to be done at all).
So before writing off Fedora/RH for stable Linux distros, I’d like clarifications. Introducing a meme OOM killer without testing it and leaving it to bring down desktop sessions with 900GB+ swap and worse than whatever was being done previously sounds pretty silly, and yet 
Added quality-team, systemd-oomd, zram
I haven’t seen any reports of it killing anyone’s desktop lately. I thought that had been cleared up some time ago.
It’s installed by default in Workstation, KDE and Server. It’s not in anything else by default AFAICS.
The Change page section you mention says “Since they are meant to be used sparingly (e.g. for critical services), its usage is limited to root owned cgroups.” AFAIK, desktop cgroups are owned by the user, not root. So they can’t be protected from OOM kill using that mechanism. Practically speaking, if a desktop system is running out of memory, it’s usually a desktop process that’s causing it, so if the OOM killer can’t kill any desktop processes, it probably can’t resolve the OOM condition…
edit: i’m not an expert, but IIUC, the way this is supposed to work is the desktop should run processes in separate cgroups, so if a compile running in a terminal is exhausting memory, the killer should just kill that cgroup, and your compilation will die but the desktop won’t. I don’t know why that apparently didn’t happen for you, whether KDE is not handling the cgroups properly or something went wrong with the killer, it’d be worth a bug report I guess. There should be some log messages from the time this happened which should provide some info on how the OOM killer decided what to do…
Yes I too had Plasma crashed when doing memory intensive tasks. As this sounds like it shouldnt happen ever, there must be something possible to fix
I had a recent “benchmark scenario” where I encoded Videos with Handbrake (nearly full CPU utilization) and ran a VM, Librewolf, Thunderbird, Signal Desktop and a few more.
Plasma did not crash! But it froze for a couple or minutes until some process was killed, once Kate, virt-manager (the VM still active), once Handbrake.
So the OOMD seems to work but Plasma still froze. I reported thid against oomd
Could implementing this be ideal?
This daemon will give resource allocations to active graphical users. Which is
done by adjusting some user-X.slice and user@X.service resource allocation
systemd properties on the fly.
…But, more importantly, the user gets a memory protection assigned to them. In
accordance with Desktop Environment Integration this resource
allocation will be distributed towards the user’s session.slice.
This sounds matching but
NOTE: This daemon is designed for obsoletion. The codebase is not supposed to
be pretty, it just needs to do the one job until other components are able
to take over in the long run.
As this relies on user systemd services as far as I understood, it seems to be related to converting all the Plasma autostart services to systemd services.