Ubuntu Developers Have An Idea For Handling The Over-Eager Systemd OOMD App Killing

[intelfx]

systemd oom has one job really: avoid the kernel oom killer waking up. If the apps causing out of memory are isolated from systemd killing, doesn't this just return us to the original problem, the invocation of the ponderous kernel oom killer?

No, that is totally incorrect. The original problem is not "invocation of the kernel oom killer", it's non-invocation of the kernel oom killer. The kernel OOM killer takes too long to react; it only wakes up when the machine is already long since unusable.

As long as something is killed and some memory is freed, the machine won't become unusable and the problem is avoided.

[oleid]

Then only show a dialog with user space processes, or processes that are safe to kill.
If no user is in front of the screen, then simply show the dialog and wait until the user is in front of the screen, in the mean time the processes needing the extra memory can just hang and wait.

Unless it is your desktop / lock screen that wants more memory, e.g. to show the dialog in the first place.

If it's a server, then again just hang the processes that are wanting the extra memory until an admin ssh into the server and select what to kill; it's not like the server will be of any use after you kill some random process.

Unless it is ssh that wants more memory because someone wants to log in.

Your server shouldn't run out of memory. If it does, the offending service should be killed to keep the server alive. And your service should survive being killed, if it is well implemented.
Nobody wants to get a call at 2am because the service stopped and someone should log in to decide to kill the service anyway.

If you have a server and you know you have memory leaking processes that are safe to restart then you can configure oom killer for your server and tell it exactly what to kill and restart.

Agreed.

In short, let the user decide what to kill, either decide on the spot or decide upfront before it happens. Don't act like you know better than the user.

I don't know anyway why this is active on Ubuntu in the first place.

[elatllat]

I'm not completely familiar with how the killer works but it might be a good idea to add another kill switch: SIGOOM which memory hungry apps like the browser should honor by killing of tabs or things like that prior to killing complete processes.

Just like iOS/Android.

We could also have light browser tabs (links2 -g) for when there is no JS/CSS3; give web developers the option to make light pages/tabs... not that many would. This page is bloated and gets a crap score 37/100

https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.phoronix.com%2Fforums%2Fforum%2Fphoronix%2Flatest-phoronix-articles%2F1330509-ubuntu-developers-have-an-idea-for-handling-the-over-eager-systemd-oomd-app-killing%2Fpage3

[sverris]

Seems to me a solution to a non-problem. I mean memory is cheap and plentiful. If you experience out-of-memory problems, your machine isn't configured properly for the use case. Don't get it .

Older hardware f.i.: RAM already maxed out, working all fine. But sometimes an app goes crazy. And then app killing would really help.

[CochainComplex]

What ever Idea it is ....it will be implemented by using snap.

[reba]

We could also have light browser tabs (links2 -g) for when there is no JS/CSS3; give web developers the option to make light pages/tabs... not that many would. This page is bloated and gets a crap score 37/100

https://pagespeed.web.dev/report?url...illing%2Fpage3

vBulletin is utter crap - for decades

[skeevy420]

Seems to me a solution to a non-problem. I mean memory is cheap and plentiful. If you experience out-of-memory problems, your machine isn't configured properly for the use case. Don't get it .

I have 32GB of ram and OOMD killed Firefox yesterday. I had a few GB sized archives open, FF+10 tabs, 3 Dolphin tabs, Gwenview, KCalc, and Kate. During that I started backing up some files to a Zstd-19 compressed directory where ZFS ballooned its memory usage and instead of ZFS giving its memory back like ZFS normally does, OOMD decided to kill Firefox.

That was the first time that OOMD killed a running process on my system. Pissed me right off.

If there is actually a problem with the algorithm or heuristics. Looks logical to me. Kill the process that keep requesting more memory = browser.

There is one. I don't know if the blame is OpenZFS or OOMD, but there is a problem. ZFS is supposed to give up memory when other programs request it. OOMD kills shit faster than ZFS can make that decision. Instead of ZFS going "Whoops, my bad, didn't mean to be so greedy. Here's some ram." Firefox gets killed.

[sinepgib]

Or the browser can at least prompt the user to close tabs

But is there anough memory for it to put the dialog on screen?

[sinepgib]

Then only show a dialog with user space processes, or processes that are safe to kill.
If no user is in front of the screen, then simply show the dialog and wait until the user is in front of the screen, in the mean time the processes needing the extra memory can just hang and wait.

What happens if the user isn't the criminal? Is the user allowed to kill anyone's process? Also, user space processes means anything but the kernel, you mean processes owned by that user?

If it's a server, then again just hang the processes that are wanting the extra memory until an admin ssh into the server and select what to kill; it's not like the server will be of any use after you kill some random process. If you have a server and you know you have memory leaking processes that are safe to restart then you can configure oom killer for your server and tell it exactly what to kill and restart.

No notification. Simply hope an admin will say "hey I'm bored let's check if we have OOM". And no, no way to notify either, until there's enough memory the system is pretty much halted.

[sinepgib]

The browser was just one example of memory hungry applications. I think every developer knows it's software requires much memory and every developer knows best what to do in case of low memory situations.

Lol no. Most developers don't know and don't care. Besides, in the end they couldn't know, the amount of memory available is only known at runtime. They can only set minimum requirements and hope.