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

  • #51
    Originally posted by jacob View Post
    Systemd also "gobbled" logind (ex-ConsoleKit), which was unmaintained abandonware.
    I despise Poettering with a passion but... ConsoleKit... nightmares resurface...

    Comment


    • #52
      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?

      Comment


      • #53
        Originally posted by terrywang View Post
        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
        Last edited by starshipeleven; 14 July 2020, 09:09 AM.

        Comment


        • #54
          Originally posted by halo9en View Post

          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?

          Comment


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

            Comment


            • #56
              Originally posted by xnor View Post
              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?
              Last edited by k1e0x; 14 July 2020, 02:06 PM.

              Comment


              • #57
                Originally posted by starshipeleven View Post
                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?

                Comment


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

                  Comment


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

                    Comment


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

                      Comment

                      Working...
                      X