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

[sinepgib]

Unlike with the kernel OOM killer, these kinds of killers kick in early, so it's not difficult for them to promise "at least X amount of RAM will be available for you to display your prompt".

Fair enough, I thought it was meant as a replacement for the eager reclaiming. What happens in the "let it sit" case, tho?

[sinepgib]

Well in such cases Ubuntu or RedHat could provide patches or press to handle these situations.

Those cases are most cases, and many of those are proprietary anyway. Ubuntu and RH don't really have the strength to press on the consumer segment, as they're the weakest players there. They try to negotiate and it ends in "ok we were just leaving enjoy your three users".
In the server and embedded market developers have better information about resources and are in charge of fixing the program, so where those companies actually do have a say the problem is pretty much moot anyway.

[ehofman]

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.

Well in such cases Ubuntu or RedHat could provide patches or press to handle these situations.

[andyprough]

systemd + oomd + snapd + gnome, what a disastrous mess. Not only that, but the combination inherently uses far more memory than needed.

Simplify. Use a distro like Void that gives you all you need with far less overhead and complexity.

Also, I agree with the poster who said Ubuntu users should be downloading more ram from the internet. But be sure and download your ram from a trusted source, like IBM/RedHat or Microsoft or Google. Or from Facebook or Twitter. Someone who respects Trusted Computing.

[deve]

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 rarely experience out-of-memory problems, but last time it was due to a bug in kwin_wayland when I opened it in a window and I was testing something in a wayland session. After ~30 seconds it ate my whole RAM and it was hard to close that window because whole gnome session became unresponsible.

The second case was indeed "machine isn't configured properly for the use case" because I was building LineageOS on machine with 8GB RAM and they increased memory requirements to 16GB. Compilation just failed after several hours, so not really a problem anyway.

[ssokolow]

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

Unlike with the kernel OOM killer, these kinds of killers kick in early, so it's not difficult for them to promise "at least X amount of RAM will be available for you to display your prompt".

[sinepgib]

For those screaming "just buy more RAM": ugh. It's tiresome to read the same dumb crap again and again.

WRT the actual problem, it seems to me it's poorly configured, and I agree with the sentiment that this functionality is mostly useful in a server anyway, where the user is expected to properly tune this kind of daemon or keep it disabled if unwilling. Normal users won't take the time to say "hmmmmm maybe this particular app should be allowed to use much more RAM than this particular other app", app by app.

[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.

[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]

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?