Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by greyseek3r View Post
    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.)

    Comment


    • #72
      Originally posted by starshipeleven View Post
      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.
      Last edited by k1e0x; 15 July 2020, 03:18 PM.

      Comment


      • #73


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

        Comment


        • #74
          Originally posted by Neuro-Chef View Post
          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.

          Comment


          • #75
            Originally posted by NotMine999 View Post
            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.

            Comment


            • #76
              Originally posted by k1e0x View Post
              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.

              Comment


              • #77
                Originally posted by greyseek3r View Post
                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.

                Comment


                • #78
                  Originally posted by starshipeleven View Post
                  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.)
                  Last edited by k1e0x; 16 July 2020, 06:14 PM.

                  Comment


                  • #79
                    Originally posted by k1e0x View Post
                    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.

                    Comment


                    • #80
                      Originally posted by starshipeleven View Post
                      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.
                      Last edited by k1e0x; 16 July 2020, 09:02 PM.

                      Comment

                      Working...
                      X