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

[k1e0x]

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.

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.

I tested this myself with chrome just opening tabs till it died. FreeBSD 12 doesn't stutter or hickup.. just boom. Once you hit OOM chrome is gone. The mouse didn't even hang.

"Users" do not provision a system in Unix land. What kind of crazyness is that? Only professional admins can provision a system.. this isn't windows. Get those users a tablet or something. lol Talk about inmates running the asylum.. next well see systemd-no-rm-r-of-slash and systemd-are-you-really-really-sure-you-want-that?.

[starshipeleven]

I tested this myself with chrome just opening tabs till it died. FreeBSD 12 doesn't stutter or hickup.. just boom. Once you hit OOM chrome is gone. The mouse didn't even hang.

Chrome does the same "clean kill" on Linux too, it sets its OOM priority extremely low.

The issue is with other processes that don't do the same. I had issues in a couple headless systems, the guy in the forum had it with firefox and other background processes.

"Users" do not provision a system in Unix land.

Go say that in FreeNAS forums or Servethehome forums and see how little you last before someone slaps you across the face. Plenty of users provisioning stuff.

[k1e0x]

Go say that in FreeNAS forums or Servethehome forums and see how little you last before someone slaps you across the face. Plenty of users provisioning stuff.

Easy, It's a joke. lol Those developer users hated that so much they created kubernetes. I guess things are all down hill from here.

[F.Ultra]

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?

Those other OS:es perhaps does not have overcommit enabled?

[starshipeleven]

Those other OS:es perhaps does not have overcommit enabled?

The "other OSes" list that don't have overcommit enabled isn't long, unless we start including high safety/reliability certified ones obviously.

Windows, Slowlaris the Unbenchmarkable, maybe some obscure BSD none uses...

Everyone else has it enabled, yes even ESXi host (the hypervisor OS from VMWare).

Would be cool if Linux flipped the switch and went with overcommit disabled by default, imho, and let the applications deal with more "failed to allocate memory" errors.

Will probably be done by systemd in a few years.

[andyprough]

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.

You're just talking in circles - you agree with me that there will be disastrous results from people believing that this resolves them of all responsibility for proper system administration. Just like they did when journaling file systems were becoming the norm, just like they've done with RAID, just like they've done with btrfs and zfs. "I don't have to do backups or monitor resource usage - systemd will protect me from data loss by intelligently killing the correct processes in an oom situation." I guarantee you the popular tech news websites will be running this kind of language in their headlines.

[k1e0x]

The "other OSes" list that don't have overcommit enabled isn't long, unless we start including high safety/reliability certified ones obviously.

Windows, Slowlaris the Unbenchmarkable, maybe some obscure BSD none uses...

Everyone else has it enabled, yes even ESXi host (the hypervisor OS from VMWare).

Would be cool if Linux flipped the switch and went with overcommit disabled by default, imho, and let the applications deal with more "failed to allocate memory" errors.

Will probably be done by systemd in a few years.

Like all things, it depends.. It's tune-able.

Here is the manual on it.
https://www.freebsd.org/cgi/man.cgi?...lt&format=html

The vm.overcommit sysctl defines the overcommit behaviour of the vm sub-system. The virtual memory system always does accounting of the swap space reservation, both total for system and per-user. Corresponding values are available through sysctl vm.swap_total, that gives the total bytes available for swapping, and vm.swap_reserved, that gives number of bytes that may be needed to back all currently allocated anonymous memory. Setting bit 0 of the vm.overcommit sysctl causes the virtual memory system to return failure to the process when allocation of memory causes vm.swap_reserved to exceed vm.swap_total. Bit 1 of the sysctl enforces RLIMIT_SWAP limit (see getrlimit(2)). Root is exempt from this limit. Bit 2 allows to count most of the physical memory as allocatable, except wired and free reserved pages (accounted by vm.stats.vm.v_free_target and vm.stats.vm.v_wire_count sysctls, respectively).

Linux's is similar, if it works? might not. It's hard to trust Linux's vm memory syb-system when we need systemd-oomd.. (The docs seem to indicate it guess at the values where as in BSD they are set by the rlimits system. Linux doesn't have that so it has to use cgroups instead.. but.. seems that isn't.. wired in? dunno.)

[starshipeleven]

Like all things, it depends.. It's tune-able.

Also on Linux, but this does not change the fact that the default option and what 99.9999% of the systems use is overcommit enabled

Linux's is similar, if it works? might not. It's hard to trust Linux's vm memory syb-system when we need systemd-oomd..

Yeah, because FreeBSD doesn't (hint: it does too).

(The docs seem to indicate it guess at the values where as in BSD they are set by the rlimits system. Linux doesn't have that so it has to use cgroups instead.. but.. seems that isn't.. wired in? dunno.)

You can set per-process memory limits with cgroups https://man7.org/linux/man-pages/man7/cgroups.7.html
and that's what systemd, monit, ulimit and any other application use to set ram usage limit per application.

[greyseek3r]

While I always enjoy having popcorn while watching people scratching each other's virtual identity with their virtual claws over a piece of software (systemd in this case), it's getting kinda repetitive and tiresome. Can we all please stop judging each others' intelligence based on how we like our FOSS systems to be? (feel free to keep judging proprietary ones.) Can we please stop mocking people who [don't] use systemd? And can we please understand what systemd is? It's not an init system anymore. It's not even a service manager anymore. It's a SYSTEM MANAGER. A system manager, by definition, manages your whole system. Every aspect of it. Boot, init, daemons, logs, directory structure, mounts, homes, now OOM situations too apparently. If you would like to have one, go use it. Luckily for those who want it, most mainstream distros have it and are using it. If you don't want it, there are alternatives, working just fine, with minimal hassle for writing a service file (s6 anyone)?

Don't mistake my comment as a criticism against criticizing something. Feel free to criticize. Criticism is constructive. Bashing is not.
If I'm allowed to have one criticism against systemd, I would say that its developers at times do not respect the domain of other software. Take the discussion about kdbus and debug as an example.

Grey out.

[k1e0x]

While I always enjoy having popcorn while watching people scratching each other's virtual identity with their virtual claws over a piece of software (systemd in this case), it's getting kinda repetitive and tiresome. Can we all please stop judging each others' intelligence based on how we like our FOSS systems to be? (feel free to keep judging proprietary ones.) Can we please stop mocking people who [don't] use systemd? And can we please understand what systemd is? It's not an init system anymore. It's not even a service manager anymore. It's a SYSTEM MANAGER. A system manager, by definition, manages your whole system. Every aspect of it. Boot, init, daemons, logs, directory structure, mounts, homes, now OOM situations too apparently. If you would like to have one, go use it. Luckily for those who want it, most mainstream distros have it and are using it. If you don't want it, there are alternatives, working just fine, with minimal hassle for writing a service file (s6 anyone)?

Don't mistake my comment as a criticism against criticizing something. Feel free to criticize. Criticism is constructive. Bashing is not.
If I'm allowed to have one criticism against systemd, I would say that its developers at times do not respect the domain of other software. Take the discussion about kdbus and debug as an example.

Grey out.

Correct, it's basically a serverless Microsoft SCOM. (or a client for a system manager.)