systemd-oomd Looks Like It Will Come Together For systemd 247

[terrywang]

Oops, Fedora 32's workstation variation (just pre-install package difference) by default installs earlyoom (user-space OOM killer). Is this just a `systemd` branded oomd? Or does it do different things?

[starshipeleven]

Oops, Fedora 32's workstation variation (just pre-install package difference) by default installs earlyoom (user-space OOM killer). Is this just a `systemd` branded oomd? Or does it do different things?

earlyOOM is a simpler system with less tunables, reusing the oom_score thing used also by the kernel oom killer.
Afaik, if both RAM and swap go below 10% free, earlyoom issues SIGTERM to the process with the largest oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL to the process with the largest oom_score. https://github.com/rfjakob/earlyoom
AFAIK this is installed by default in Fedora 32 and avaliable in most other distros.

The oom daemon that will go into systemd should be the one from Facebook, and it is more advanced as it's looking at more detailed ram usage of stuff using a more granular API that was merged in Linux kernel, tracking processes using cgroups.

https://github.com/facebookincubator/oomd

That said, if all you want is avoiding to freeze the system, it's enough to install earlyoom. systemd's new daemon will probably be for more serious usage

[finalzone]

I despise Poettering with a passion but... ConsoleKit... nightmares resurface...

You despite a person doing a great job at advancing the whole core Linux ecosystem while giving the chance of other developers(who chose to do nothing) to at least maintain an depreciated software? Really?

[andyprough]

If you think systemd killing process is a disaster waiting to happen, you won't believe what disasters the kernel OOM actually does reliably. Like soft-locking the system in an unresponsive mode if there is swap at all.

Not everyone enjoys babysitting a machine that can and should deal with it on its own

Oh, I would absolutely believe it, which is why I use proper hardware setups, excess ram, constant incremental data backups, frequent incremental system file backups, and pay attention that my processes don't overload my system. But I can tell you, you can stick your head in the sand and scream "LA LA LA LA NOTHING TO SEE HERE" and ignore the enormous numbers of unresolved systemd issues that are posted online - but none of that is going to save one single bit of your data - not one single 1 or 0 - if you are ignorantly relying on someone else's sloppy code to replace good administrative practice. If you know what you are doing and have good admin practices, it really doesn't matter what oom manager or init manager you use - you'll figure out how to do it safely. You and I know how to run a system well no matter what the init system - but we also know that the world is filled with the kind of people who are going to rely on oomd as some kind of magical fairy dust that means they don't need any backup plan and they are going to get themselves into huge trouble. They did it with journaling file systems, they did it with RAID, they do it every day with zfs and btrfs, and there is absolute certainty they will do it with oomd, and then whine about it after they've suffered unrecoverable data loss.

[k1e0x]

One word: ignorance.
Again, people that don't know what they're talking about and haven't got the first clue about how Linux handles OOM situations ideologically condemn it because it has "systemd" in its name.

But it really doesn't it crashes. That is why this exists in Linux. No other OS needs this, the kernel just does it there.

Maybe they have a political structure that allows for people to fix the OS kernel without bandaids and hacks. Who knows?

[tildearrow]

Political problemsrequire political solutions. Touching kernel code is a pain in the ass and you also need to convince people that it is a problem at all (afaik they are not convinced in the lkml). It's much easier to just move that to a userspace application.

Let's think of an out-of-tree kernel module...

...isn't there a sysctl option to disable exec code swapping?

[starshipeleven]

Oh, I would absolutely believe it, which is why I use proper hardware setups, excess ram, constant incremental data backups, frequent incremental system file backups, and pay attention that my processes don't overload my system.

all of the above (apart from the provisioning phase of course) can be handled by the machine.

ignore the enormous numbers of unresolved systemd issues that are posted online

Well, we are ignoring ZFS, btrfs, firefox, chromium, KDE, GNOME and Linux issues posted online already and all is still fine. It will be fine if we ignore systemd issues too, trust me.

If you know what you are doing and have good admin practices, it really doesn't matter what oom manager or init manager you use - you'll figure out how to do it safely.

I'd really rather fucking not, I've had my days with pre-SP2 XP. I'm not using a Linux From Scratch setup, distro maintainers have set up the system, I'm just using it to do stuff.

You and I know how to run a system well no matter what the init system

You mean "you and I know how to run a pre-configured distro with an installer or at least a tutorial to install it" right?

people who are going to rely on oomd as some kind of magical fairy dust that means they don't need any backup plan and they are going to get themselves into huge trouble.

dunno, maybe I'm a savage, but I think that if someone thinks that a daemon that kills applications when there is low RAM isn't going to cause data loss (by killing applications when there is low RAM, you know, closing without saving), they are a bit retarded.

[starshipeleven]

Let's think of an out-of-tree kernel module...

being in-kernel does not give this any benefit, which is why it's a userspace daemon.

...isn't there a sysctl option to disable exec code swapping?

I'm not sure I understand. There is a sysctl option to disable the whole OOM thing, but it does not hurt to leave it there as if you get so far into the shit that it's triggered you are screwed anyway.

[starshipeleven]

No other OS needs this,

I "heard" FreeBSD has the same crappy OOM killer functionality https://forums.freebsd.org/threads/out-of-memory.69755/
I also experienced that a few times.

Maybe they have a political structure that allows for people to fix the OS kernel without bandaids and hacks.

or maybe they blame the user for "not provisioning the system correctly and can only work around the problem with custom hacks, while on Linux there are like 4 different userspace OOM daemons now.

[xnor]

I may be the ignorant one here .... but why can't they simply improve the already available OOM mechanism in the kernel ? So far I don't see any need for this to be systemd exclusice ?

That's also a main issue with systemd haters from what I can see. It gobbles up various things that originated elsewhere and improves them killing the original project in the process... very Microsoft-like if you ask me ...

Yeah, the main issue with systemd haters is ignorance. The kernel OOM killer's job is to protect the kernel from OOM situations. User-space may have been locked for minutes (!) before the kernel OOM starts killing, which can be minutes too late. Also, because it doesn't care about what your system does and looks like from a logical point of view it will make wrong decisions.

From the kernel's pov all is fine. From a user's pov it's not the right tool, it's dumb and it's slow to react and makes wrong decisions.