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

[k1e0x]

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

Yeah, because FreeBSD doesn't (hint: it does too).
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.

The difference is in FreeBSD rlimits works with the kernel swap and oom settings. In Linux cgroups doesn't seam to and needs systemd? At least in this case it doesn't appear to be tied into the kernel. Might be part of the benefit of having a complete OS made by one single group.


I still feel this is a ugly hack.. it should be fixed in the kernel but whatever.. isn't the first and won't be the last in Linux.

[k1e0x]

And.. here you go.. seems FreeBSD's kernel OOM killer works just fine.

[NotMine999]

OK. But hanging / crashing servers can really help choosing quality vendors next time..

Right idea but wrong solution. Solid hardware can have issues, but experience has taught me that quality hardware tends to encounter software problems more often than hardware problems. So let's stop blame-shifting the issue.

Poorly configured software on a server usually indicates poor choices made in staffing server administration & server applications (DevOps) teams.

[Neuro-Chef]

Right idea but wrong solution. Solid hardware can have issues, but experience has taught me that quality hardware tends to encounter software problems more often than hardware problems. So let's stop blame-shifting the issue.

Poorly configured software on a server usually indicates poor choices made in staffing server administration & server applications (DevOps) teams.

Yes, and often enough you can't really change that. And there are (closed source) software vendors.

[starshipeleven]

In Linux cgroups doesn't seam to and needs systemd? At least in this case it doesn't appear to be tied into the kernel.

Yeah, we totally need systemd to write ascii into some /sys/kernel/cgroup folder, did you read the doc? What does it even mean "tied into the kernel"? Who is enforcing the cgroup rules? The kernel is doing it, that's the whole point.

Cgroups are used by containers, flatpak, Apparmor/SELinux and more.

I still feel this is a ugly hack.. it should be fixed in the kernel but whatever.. isn't the first and won't be the last in Linux.

Yes it should be fixed in the kernel I won't disagree, but I find amusing how you call "hacks" things that follow Unix principles (you know) only when it is about Linux.

And.. here you go.. seems FreeBSD's kernel OOM killer works just fine.

"WORKSFORME" does not mean what I and that guy in the forum experienced is false. It just means that the bug isn't as obvious as with Linux's OOM.

[starshipeleven]

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.

"Systemd the application" is still an init, just like it always was. "Systemd the project" is a bunch of tools and deamons that form the core of a linux distro userspace. Really, there is a bootloader in there too.

I personally believe that if Lennart called the "core of a linux distro project" with a different name he would have avoided a lot of flak and confusion.

[k1e0x]

Yeah, we totally need systemd to write ascii into some /sys/kernel/cgroup folder, did you read the doc? What does it even mean "tied into the kernel"? Who is enforcing the cgroup rules? The kernel is doing it, that's the whole point.

Cgroups are used by containers, flatpak, Apparmor/SELinux and more.

Yes it should be fixed in the kernel I won't disagree, but I find amusing how you call "hacks" things that follow Unix principles (you know) only when it is about Linux.

"WORKSFORME" does not mean what I and that guy in the forum experienced is false. It just means that the bug isn't as obvious as with Linux's OOM.

Yeah.. lol.. I know you got problems seeing truth.

And the guy in the forum you googled as "proof" wasn't even asking about this. Find out for yourself. it's easy enough. Download the GhostBSD ISO into virtualbox install it (because the CD run on a ramdisk) and run that piece of code. FreeBSD did not crash, when under memory pressure. It also chose the proper app to kill. No systemd-oomd needed.

Dude it's such a mess.. most of this apparmor/selinux stuff is to cover up holes in the design the kernel team has marked as "won't fix".

$ ls /sys
ls: /sys: No such file or directory
$ ls /proc
$

These Unix principles you are talking about.. hmm.. These folders don't seem to exist on actual Unix.. (The only reason proc exists is to provide a mount point for linux emulation.)

[starshipeleven]

FreeBSD did not crash, when under memory pressure. It also chose the proper app to kill. No systemd-oomd needed.

That's not what I saw or he saw.

Dude it's such a mess.. most of this apparmor/selinux stuff is to cover up holes in the design the kernel team has marked as "won't fix".

Um, it's about setting policies to limit application accessing system resources and folders, but feel free to imagine things.

These Unix principles you are talking about..

Unix principles, you know, the things that you heathens use to shit on systemd saying it's not modular and that it's not doing "one thing and doing it well", and that stringing together little applications in a script to do something bigger is so much better.

But when something is doing just that (each Linux kernel feature does a single simple thing and does it well, and it is combined with others to do bigger and more complex things) then it's bad because it's Linux and you are butthurt about Linux stealing all the press.

[k1e0x]

That's not what I saw or he saw.

Um, it's about setting policies to limit application accessing system resources and folders, but feel free to imagine things.

Unix principles, you know, the things that you heathens use to shit on systemd saying it's not modular and that it's not doing "one thing and doing it well", and that stringing together little applications in a script to do something bigger is so much better.

But when something is doing just that (each Linux kernel feature does a single simple thing and does it well, and it is combined with others to do bigger and more complex things) then it's bad because it's Linux and you are butthurt about Linux stealing all the press.

If you look closely Linux is the thing that stings together a lot of little scripts. Dig into Ubuntu's wifi some.. I dare you. Scripts, calling scripts, calling scripts. FreeBSD put wifi support into ifconfig.. because ifconfig is the program to manage network interfaces in the system and.. well.. it's a network interface. Plan and design. Linux did 25 different things. The evolutionary winners were.. who knows what it is today.. netplan or network-manager or god knows..

Unix has shown itself to be the right model for computing.. We know this as fact because it's still around it dominated the earth and it's competitors like Windows NT (and other large monolithic feature rich software) isn't and didn't at least in the datacenter and enterprise. I'm not saying you have to treat it as religion or that improvements can't be made but after 50 years of one model of computing surviving, you might do some serious thought and reflection before you decide to try something else. In other words, the model works and it's effective and we have decades of proof.

[oiaohm]

If you look closely Linux is the thing that stings together a lot of little scripts. Dig into Ubuntu's wifi some.. I dare you. Scripts, calling scripts, calling scripts. FreeBSD put wifi support into ifconfig.. because ifconfig is the program to manage network interfaces in the system and.. well.. it's a network interface. Plan and design. Linux did 25 different things. The evolutionary winners were.. who knows what it is today.. netplan or network-manager or god knows..

https://github.com/freebsd/freebsd/b...fig/ifconfig.c http://net-tools.sourceforge.net/
ifconfig on and bsd is in fact different to ifconfig on linux. So ifconfig on Linux has been developed independent of kernel work.

Now if you are after the Linux true equal to ifconfig on freebsd we are talking

https://wiki.linuxfoundation.org/networking/iproute2

The ip command. This has not been evolutionary winners. Iproute2 is a kernel.org project that was made because the independent projects like net-tools came basically a mess of what features they did and did not support and iproute2 was basically start from scratch because everything was a mess.

Network manager is in fact something different. https://www.freshports.org/net-mgmt/networkmgr/ Yes GhostBSD was first to make their own clone of Linux network manager and now other BSD are picking this up. Its not ifconfig or ip command stuff but a higher level of abstraction same with netplan.

Unix has shown itself to be the right model for computing..

Are you really sure.

We know this as fact because it's still around it dominated the earth and it's competitors like Windows NT (and other large monolithic feature rich software) isn't and didn't at least in the datacenter and enterprise.

This is kind of wrong. In large section of the datacenter and enterprise Linux not Unix because Linux is cheap. Linux has basically crushed commercial Unix out of most markets. Linux does not perfectly match Unix either.

I'm not saying you have to treat it as religion or that improvements can't be made but after 50 years of one model of computing surviving, you might do some serious thought and reflection before you decide to try something else. In other words, the model works and it's effective and we have decades of proof.

Except this is kind of wrong in about year 2000. Linux basically defeated Unix. So its not 50 years of success. 20 years ago Unix lost it location. About year 2000 you see the body talking about Unix standards talking about using Linux syscalls going forwards. Unix to Linux move gives us how long you need to replace a model. 9-10 years of proof that the new model works so decades of proof is pointless the last decade of proof is the important bit to start growing migrations.

The reality here is what Linux did not kill of commercial Unix the BSD end up cleaning up most of the market. Unix today is basically scraps.

Posix standard that define unix if you look closely has not been updated really since 2008. Yes the 2017 release was basically bind into the 2008 standard two 2008 optional extras and that was the total of the Posix Standard 2017 changes. There is really no Posix standard work any more. So now Linux is going it own way. Some *bsd developers have been starting to see this as well.

Its basically heading on the path Unix is dead long live Linux.