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

  • #61
    Originally posted by haplo602 View Post

    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.
    Last edited by xnor; 14 July 2020, 03:38 PM.

    Comment


    • #62
      Originally posted by starshipeleven View Post
      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?.
      Last edited by k1e0x; 14 July 2020, 03:20 PM.

      Comment


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

        Comment


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

          Comment


          • #65
            Originally posted by k1e0x View Post

            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?

            Comment


            • #66
              Originally posted by F.Ultra View Post
              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.

              Comment


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

                Comment


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

                  Comment


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

                    Comment


                    • #70
                      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.

                      Comment

                      Working...
                      X