13 ms·

Systemd 248 RC3: systemd-oomd is now considered fully supported

84 points by marcodiego 6y ago

hedora 6y ago
> A concept of system extension images is introduced. Such images may be used to extend the /usr/ and /opt/ directory hierarchies at runtime with additional files (even if the file system is read-only). When a system extension image is activated, its /usr/ and /opt/ hierarchies and os-release information are combined via overlayfs with the file system hierarchy of the host OS. Oh, what fresh hell is this?
- chunkyks 6y ago
  To be fair overlay fs is a good way to manage network boot / nfs root systems, live cds... All sorts of things where I want an underlying fs that clients can't mess with but they still need to think they can write to it
  - hedora 6y ago
    Overlays are fine. I’ve used them for all sorts of stuff. Tying them to pid 1, and forcing them to be used all the time for some hacked up thing where /usr is different depending on which process is looking at it? Not so much.
    - Spivak 6y ago
      It’s not a hacked thing, it’s filesystem namespaces exactly as is done in Docker so that a container process doesn’t mess up its image. It’s no more privilege than pid 1 had before because of .mount units.
    - Denvercoder9 6y ago
      > forcing them to be used all the time You know this doesn't do anything unless explicitly configured in the system and/or unit configuration?
- viraptor 6y ago
  It's basically the ostree idea on a smaller scale. Did you ever want to install some proprietary software with access to system libraries/config, but without actually polluting the global namespace? It's this. Like running a docker service with host as your base layer. (Minus other namespaces) Honestly, it seems great and not very tricky for a system which already manages namespaces with private mounts.
  - e12e 6y ago
    There's a pretty big difference between "ghosting" /opt, /srv, /usr/local/ - and munging all/any of /usr?
    - viraptor 6y ago
      Not sure what you mean either by ghosting or by munging to be honest...
      - e12e 6y ago
        Munging - messing with. Per the (somewhat abandoned)standard for filesystem layout /usr (except /usr/local) is the domainof the system/distribution. It's not very nice for a package to stomp on that. Although systemd already claim some authority over logs via journalctl of course. Ghosting: by bind-mounting over the system fs -you might introduce a bug/condition that doesn't show up in a recovery boot scenario, or forensic analyzis of the filesystem/disk - you could introduce "ghost" files/artefacts.
        viraptor 6y ago
        > It's not very nice for a package to stomp on that. Yes, sure. That doesn't stop hundreds of vendors with custom install scripts who will use /usr and /opt which is the current state of things. Systemd actually provides a workaround here which stops that package from changing those hierarchies globally, which... seems like something you'd want? > you might introduce a bug/condition that doesn't show up in a recovery boot scenario Why would you try to run anything but recovery tools in a recovery boot scenario? > or forensic analyzis of the filesystem/disk You can reproduce the same environment using the same overlay configuration - that setup is not hidden from you. It's not any more confusing in forensic than a docker service and we deal with them (including bind-mounts) just fine.
- IgorPartola 6y ago
  Just because it comes from systemd doesn’t mean it’s a bad idea. OpenWRT and other embedded Linux systems use overlay file systems very effectively.
- crooked-v 6y ago
  There's actually a directly analogous case in the gaming world, of all things: the app Mod Organizer 2 uses a runtime virtual file system There's actually a directly analogous case in the gaming world, of all things: the app Mod Organizer 2 uses a runtime-only virtual file system to layer together the files from different mod packages, making it easy to adjust for and dynamically disable/enable overlapping mod resource files (of which there can be a huge number in games like Skyrim), as well as redirecting output files from mods to a sane holding area instead of letting them pollute your game installs.
- 2ion 6y ago
  It's a fine concept. Good for replacing stuff like appimage besides the packaging part? Mixing this with OS package management will require some consideration. So they are using overlayfs, which means that "upper" directories have visibility precedence on file name conflict. Which means that some auditing facility should be required that alerts if an upper sys image masks a lower one, or if an OS package some time later installs a file to the "lower" directory, perhaps the original rootfs, but a sysfs package still takes precedence…
chunkyks 6y ago
Soon it'll include a browser and email client. Can't wait!
- __turbobrew__ 6y ago
  GNU/Linux will soon be replaced by Systemd/Linux
  - Karunamon 6y ago
    You meme, but they're eating so many userspace components that this is actually where I see them heading. Just wait until ls has to have hooks into dbus to do its job.
  - marcodiego 6y ago
    Actually, I don't think something like busybox included in systemd is necessarily bad. You could have a system recoverable even if everything else breaks. Of course, it would really enable systemd/linux.
    - hexo 6y ago
      It doesnt need to be included in systemd for that.
    - toast0 6y ago
      Shhhh. Don't give them ideas. Including busybox in the initrd or whatever it's called now is probably a good idea. Having systemd developers write a new interpretation of that, rehashing old bugs is not great.
    - tyingq 6y ago
      Most of what you would need to cobble together a busybox like binary is there in the systemd/src/basic directory. stat-util, procfs-util, sort-util, path-util, and so on.
    - anthk 6y ago
      OpenBSD has a ramdisk for that.
marcodiego 6y ago
Linux oom behavior always has had complaints[0]. Hope it now finally fixes the desktop case[1]. [0] https://lwn.net/Articles/104185/ https://lwn.net/Articles/104185/ [1] https://lkml.org/lkml/2019/8/4/15 https://lkml.org/lkml/2019/8/4/15
- warmwaffles 6y ago
  [0] was a humorous read. I love these little analogies.
  - bscphil 6y ago
    It's kind of a funny analogy in the context of systemd-oomd, because the latter is sort of like saying "hmm, when the plane is out of fuel, sometimes there's not enough power to actually eject anyone from the plane, so we're going to start ejecting people while there's still a little bit of fuel left!"
- bscphil 6y ago
  For reference, [1] describes the SSD near-OOM thrash problem, where the speed of refaulting file pages is so high that the kernel detects enough activity and doesn't trigger OOM. It's a heck of a problem to deal with, and a OOM killer will go part of the way to fixing it, but I still have two complaints about the thrash problem. 1. In similar situations on other operating systems, I don't usually see the GUI freeze to an unusable state. In Linux hitting a thrash situation will freeze the computer to the point where Ctrl-Alt-F2 will not switch the vterm even when waiting several minutes, and it has to be rebooted. I suppose it's possible that I just haven't used other OSes enough in a long time and they have this too, but this seems like a solvable problem. I assume it's not a CPU issue, since the scheduler should handle that just fine. So why not have a mechanism by which the user's desktop environment and init / login system can reserve itself enough memory to always be responsive under any memory condition? 2. Browsers. The state of browser memory management is atrocious. Just about every time I've run out of memory (other than compiling some complex software with -O3) it's been because my browser is hogging a huge chunk of it (even if the OOM killer blames something else). Now, I understand that in theory unused memory is wasted memory. So a browser using a ton of memory can be a good thing. But this is only true when memory the browser is holding but not using can be reclaimed to be used by another program, and this seems to basically never happen. If I close and reopen the browser (with the tabs automatically restored) the memory usage drops by 80% or more; the issue is that the browser simply never suspends tabs I haven't used in days or weeks. Modern browsers are not good "desktop citizens", if you will. They hog memory to the point where opening anything new will create a pressure stall. I suspect solving these two issues would largely fix thrashing for most desktop users, without the need to ever kill anything, which is obviously undesirable. Feel free to tell me if one or both of these is incorrect or impossible. These are just my observations, I'm not a kernel dev or anything close to one.
yawaramin 6y ago
I actually don't understand why systemd-oomd is needed given MemoryMax= ( https://man7.org/linux/man-pages/man5/systemd.resource-control.5.html https://man7.org/linux/man-pages/man5/systemd.resource-contr... ). What are they doing differently?
- danobi 6y ago
  When a cgroup hits its memory.max the kernel OOM killer is invoked. systemd-oomd enables finer grained policy than the kernel OOM killer. systemd-oomd can also prevent livelocks (which memory.max does not).
- geofft 6y ago
  I think the distinction is that MemoryMax= is just an interface to the cgroupv2 setting, i.e., that rule is implemented inside the kernel and invokes the kernel's OOM killer within a cgroup. The manpage for systemd-oomd says, "systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space." It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd https://github.com/facebookincubator/oomd https://github.com/facebookincubator/oomd , whose documentation gives a bunch of reasons as to why you would prefer a userspace oomd that takes in PSI data and can be configured to proactively kill misbehaving processes instead of just letting the kernel OOM killer handle it. The major reason is time to recovery: a misbehaving process can cause a system to be so far under pressure that the kernel OOM killer will take a long time to flush things out, but a userspace component can respond in advance with more configurable rules (and more flexibility, since the kernel doesn't believe you're at capacity yet).
  - danobi 6y ago
    Yes, exactly. > It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd Yep, I authored the original standalone oomd (along with many others' help) and Anita has been working on systemd-oomd. There's plans to converge and simplify everything that's been learned from oomd into systemd-oomd so the community can benefit from all our experiments.
iio7 6y ago
Could they maybe start handling the 1400+ bugs that has been a part of systemd for such a long time (some unresolved since 2015) rather than keep adding and adding and adding and adding code!
- jbverschoor 6y ago
  Feel free to contribute to open source projects!
- jabiko 6y ago
  There are a lot of open issues but you are a bit unfair in calling them bugs. If you filter out the RFEs (Requests For Enhancement) you find 617 issues. If you filter for only issues labeled as a bug you get 97 results.
  - stonogo 6y ago
    OK, but they don't always label bugs that way (example: systemd/#5616) and the bugs that are labeled can get pretty old (systemd/#3700). Furthermore a lot of RFEs are really just disguised bug reports (systemd/#5917 is just an RFE rephrasing of system/#3700). In my experience, unless you can get Red Hat to care about patching a specific bug, you can rely on opened bugs to stay open.
    - viraptor 6y ago
      I didn't dig into others, but: > don't always label bugs that way (example: systemd/#5616) Nobody figured out if that issue is in logind or X yet. They did not close it so it's not like they say it can't possibly be on systemd side. (typical Lennart comments aside)
- zokier 6y ago
  People add features they need, and fix bugs that impact them. Scratching your own itch is the fundamental principle in open source. I recommend you to do the same.
znpy 6y ago
I have some questions. I started reading about systemd-oomd, then followed the link to its manpage (at https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.html https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.htm...) then followed a link from there to this page: "In defence of swap: common misconceptions" at https://chrisdown.name/2018/01/02/in-defence-of-swap.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html). The first line of the tl;dr is: "Having swap is a reasonably important part of a well functioning system. Without it, sane memory management becomes harder to achieve." Now, afaik linux as a kernel is pretty much designed to have swap memory and really not meant to be ran without it. Except disabling swap is required to run kubernetes, so much so that the kubelet will plain refuse to start if it detects swap memory enabled. Why?
- geofft 6y ago
  This is one of the primary reasons the Kubernetes folks are working on letting you run with swap! See recent discussion in https://github.com/kubernetes/kubernetes/issues/53533 https://github.com/kubernetes/kubernetes/issues/53533 . The historic reason Kubernetes didn't let you run with swap is that it's complicated from a resource management perspective - it's not clear whether each pod should be requesting some amount of swap the same way it requests some amount of RAM, and also the container runtimes didn't really have support for that (largely because you need cgroupv2 to have a hope of that sort of per-cgroup swap resource control working at all). But it's not an insurmountable problem, and it sounds from that ticket like they recognize that letting systems have swap enabled for the sake of a userspace oomd is an important use case.
- xyzzy_plugh 6y ago
  Why is Linux not meant to be ran without swap? In 2021? I've never heard of this. I've operated massive clusters of thousands of hosts with no swap enabled with zero hiccups. Swap comes with a lot of caveats -- when a performance-critical process begins swapping it can on occasion be more useful to just let it OOM instead. My personal desktop has 64GB of memory, with no swap enabled. Why would I want swap it I don't need more than that?
  - 6y ago
diegocg 6y ago
If you want to understand why a oomd daemon is necessary and oom alone is not enough, you might be interested in this talk from FB "Linux memory management at scale" https://youtube.com/watch?v=cSJFLBJusVY https://youtube.com/watch?v=cSJFLBJusVY
- Foxboron 6y ago
  The finished talk with a (short) Q&A can be also be found. https://media.ccc.de/v/arch-conf-online-2020-6390-linux-memory-management-at-scale https://media.ccc.de/v/arch-conf-online-2020-6390-linux-memo... Q&A Questions: https://gitlab.archlinux.org/archlinux/conf-files/-/blob/master/2020/archconf/talks/Linux%20memory%20management%20at%20scale/questions.md https://gitlab.archlinux.org/archlinux/conf-files/-/blob/mas...
- noobermin 6y ago
  Can anyone provide a summary or short set of reasons? Proof by link to 40 minute video doesn't feel satisfactory.
  - IshKebab 6y ago
    I mean, picking a process to kill at random is obviously a crap solution. Windows has done better than that for decades.
wooptoo 6y ago
They missed the opportunity to call it systemd-doom.
- hhh 6y ago
  systemd-oom
Klwohu 6y ago
That change log is HUGE and it’s the main reason we don’t use systemd. Creeping featurism isn’t good in your OS when you need things to be consistent and work the same every time. Systemd has a lot of state.
- greyw 6y ago
  Who is we? I use systemd on the operating systems I use (debian, centos and opensuse)
  - Klwohu 6y ago
    Our organization. It doesn’t make sense to rely on software which grows to consume all available niches. Systemd is a perfect example of this kind of software. I don’t wish to have to ascertain what new features it’s reimplemented, sometimes in ways which are not POSIX compliant, every time there’s an update.
    - esarbe 6y ago
      Do I guess correctly that your organization doesn't value clean services initialization, solid services dependencies management and reliable log handling? Well, there must be room for such organizations too. It's a colorful world after all.
      - Klwohu 6y ago
        No, we get all of that with time-worn traditional methods which work well, are documented properly, and conform to standards. I’m not interested in beta testing Red Hat’s replacement for Linux.
- dgellow 6y ago
  I'm very happily using systemd since a bit less than a decade now. It's fantastic to have a common standardized way to manage your services and jobs that doesn't rely on a fragile set of scripts, and unified logs that can be easily queried and exported to a machine readable format.
p4cmanus3r 6y ago
Am I the only one excited about support for luks via TPM?
The_rationalist 6y ago
How will systemd-oomd communicate to the user? I was using https://github.com/hakavlad/nohang https://github.com/hakavlad/nohang And it sent notification signaling to save your work before the application X will be killed. (I always wanted a way to click somewhere on the notification to prevent nohand from killing it when unwanted) Also nohang use PSI data does oomd does it too? Finally the author of nohang is working on arguably superior solutions: https://github.com/hakavlad/prelockd https://github.com/hakavlad/prelockd https://github.com/hakavlad/memavaild https://github.com/hakavlad/memavaild https://github.com/hakavlad/le9-patch https://github.com/hakavlad/le9-patch It's unfortunate that systemd has chosen to integrate an inferior solution
flippinburgers 6y ago
Systemd is such a wonderful example of "if I didn't develop it, it isn't good enough."

84 points by marcodiego 6y ago

> A concept of system extension images is introduced. Such images may be used to extend the /usr/ and /opt/ directory hierarchies at runtime with additional files (even if the file system is read-only). When a system extension image is activated, its /usr/ and /opt/ hierarchies and os-release information are combined via overlayfs with the file system hierarchy of the host OS. Oh, what fresh hell is this?

chunkyks 6y ago
To be fair overlay fs is a good way to manage network boot / nfs root systems, live cds... All sorts of things where I want an underlying fs that clients can't mess with but they still need to think they can write to it
- hedora 6y ago
  Overlays are fine. I’ve used them for all sorts of stuff. Tying them to pid 1, and forcing them to be used all the time for some hacked up thing where /usr is different depending on which process is looking at it? Not so much.
  - Spivak 6y ago
    It’s not a hacked thing, it’s filesystem namespaces exactly as is done in Docker so that a container process doesn’t mess up its image. It’s no more privilege than pid 1 had before because of .mount units.
  - Denvercoder9 6y ago
    > forcing them to be used all the time You know this doesn't do anything unless explicitly configured in the system and/or unit configuration?
viraptor 6y ago
It's basically the ostree idea on a smaller scale. Did you ever want to install some proprietary software with access to system libraries/config, but without actually polluting the global namespace? It's this. Like running a docker service with host as your base layer. (Minus other namespaces) Honestly, it seems great and not very tricky for a system which already manages namespaces with private mounts.
- e12e 6y ago
  There's a pretty big difference between "ghosting" /opt, /srv, /usr/local/ - and munging all/any of /usr?
  - viraptor 6y ago
    Not sure what you mean either by ghosting or by munging to be honest...
    - e12e 6y ago
      Munging - messing with. Per the (somewhat abandoned)standard for filesystem layout /usr (except /usr/local) is the domainof the system/distribution. It's not very nice for a package to stomp on that. Although systemd already claim some authority over logs via journalctl of course. Ghosting: by bind-mounting over the system fs -you might introduce a bug/condition that doesn't show up in a recovery boot scenario, or forensic analyzis of the filesystem/disk - you could introduce "ghost" files/artefacts.
      - viraptor 6y ago
        > It's not very nice for a package to stomp on that. Yes, sure. That doesn't stop hundreds of vendors with custom install scripts who will use /usr and /opt which is the current state of things. Systemd actually provides a workaround here which stops that package from changing those hierarchies globally, which... seems like something you'd want? > you might introduce a bug/condition that doesn't show up in a recovery boot scenario Why would you try to run anything but recovery tools in a recovery boot scenario? > or forensic analyzis of the filesystem/disk You can reproduce the same environment using the same overlay configuration - that setup is not hidden from you. It's not any more confusing in forensic than a docker service and we deal with them (including bind-mounts) just fine.
IgorPartola 6y ago
Just because it comes from systemd doesn’t mean it’s a bad idea. OpenWRT and other embedded Linux systems use overlay file systems very effectively.
crooked-v 6y ago
There's actually a directly analogous case in the gaming world, of all things: the app Mod Organizer 2 uses a runtime virtual file system There's actually a directly analogous case in the gaming world, of all things: the app Mod Organizer 2 uses a runtime-only virtual file system to layer together the files from different mod packages, making it easy to adjust for and dynamically disable/enable overlapping mod resource files (of which there can be a huge number in games like Skyrim), as well as redirecting output files from mods to a sane holding area instead of letting them pollute your game installs.
2ion 6y ago
It's a fine concept. Good for replacing stuff like appimage besides the packaging part? Mixing this with OS package management will require some consideration. So they are using overlayfs, which means that "upper" directories have visibility precedence on file name conflict. Which means that some auditing facility should be required that alerts if an upper sys image masks a lower one, or if an OS package some time later installs a file to the "lower" directory, perhaps the original rootfs, but a sysfs package still takes precedence…

chunkyks 6y ago

Soon it'll include a browser and email client. Can't wait!

__turbobrew__ 6y ago
GNU/Linux will soon be replaced by Systemd/Linux
- Karunamon 6y ago
  You meme, but they're eating so many userspace components that this is actually where I see them heading. Just wait until ls has to have hooks into dbus to do its job.
- marcodiego 6y ago
  Actually, I don't think something like busybox included in systemd is necessarily bad. You could have a system recoverable even if everything else breaks. Of course, it would really enable systemd/linux.
  - hexo 6y ago
    It doesnt need to be included in systemd for that.
  - toast0 6y ago
    Shhhh. Don't give them ideas. Including busybox in the initrd or whatever it's called now is probably a good idea. Having systemd developers write a new interpretation of that, rehashing old bugs is not great.
  - tyingq 6y ago
    Most of what you would need to cobble together a busybox like binary is there in the systemd/src/basic directory. stat-util, procfs-util, sort-util, path-util, and so on.
  - anthk 6y ago
    OpenBSD has a ramdisk for that.

marcodiego 6y ago

Linux oom behavior always has had complaints[0]. Hope it now finally fixes the desktop case[1]. [0] https://lwn.net/Articles/104185/ https://lwn.net/Articles/104185/ [1] https://lkml.org/lkml/2019/8/4/15 https://lkml.org/lkml/2019/8/4/15

warmwaffles 6y ago
[0] was a humorous read. I love these little analogies.
- bscphil 6y ago
  It's kind of a funny analogy in the context of systemd-oomd, because the latter is sort of like saying "hmm, when the plane is out of fuel, sometimes there's not enough power to actually eject anyone from the plane, so we're going to start ejecting people while there's still a little bit of fuel left!"
bscphil 6y ago
For reference, [1] describes the SSD near-OOM thrash problem, where the speed of refaulting file pages is so high that the kernel detects enough activity and doesn't trigger OOM. It's a heck of a problem to deal with, and a OOM killer will go part of the way to fixing it, but I still have two complaints about the thrash problem. 1. In similar situations on other operating systems, I don't usually see the GUI freeze to an unusable state. In Linux hitting a thrash situation will freeze the computer to the point where Ctrl-Alt-F2 will not switch the vterm even when waiting several minutes, and it has to be rebooted. I suppose it's possible that I just haven't used other OSes enough in a long time and they have this too, but this seems like a solvable problem. I assume it's not a CPU issue, since the scheduler should handle that just fine. So why not have a mechanism by which the user's desktop environment and init / login system can reserve itself enough memory to always be responsive under any memory condition? 2. Browsers. The state of browser memory management is atrocious. Just about every time I've run out of memory (other than compiling some complex software with -O3) it's been because my browser is hogging a huge chunk of it (even if the OOM killer blames something else). Now, I understand that in theory unused memory is wasted memory. So a browser using a ton of memory can be a good thing. But this is only true when memory the browser is holding but not using can be reclaimed to be used by another program, and this seems to basically never happen. If I close and reopen the browser (with the tabs automatically restored) the memory usage drops by 80% or more; the issue is that the browser simply never suspends tabs I haven't used in days or weeks. Modern browsers are not good "desktop citizens", if you will. They hog memory to the point where opening anything new will create a pressure stall. I suspect solving these two issues would largely fix thrashing for most desktop users, without the need to ever kill anything, which is obviously undesirable. Feel free to tell me if one or both of these is incorrect or impossible. These are just my observations, I'm not a kernel dev or anything close to one.

yawaramin 6y ago

I actually don't understand why systemd-oomd is needed given MemoryMax= ( https://man7.org/linux/man-pages/man5/systemd.resource-control.5.html https://man7.org/linux/man-pages/man5/systemd.resource-contr... ). What are they doing differently?

danobi 6y ago
When a cgroup hits its memory.max the kernel OOM killer is invoked. systemd-oomd enables finer grained policy than the kernel OOM killer. systemd-oomd can also prevent livelocks (which memory.max does not).
geofft 6y ago
I think the distinction is that MemoryMax= is just an interface to the cgroupv2 setting, i.e., that rule is implemented inside the kernel and invokes the kernel's OOM killer within a cgroup. The manpage for systemd-oomd says, "systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space." It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd https://github.com/facebookincubator/oomd https://github.com/facebookincubator/oomd , whose documentation gives a bunch of reasons as to why you would prefer a userspace oomd that takes in PSI data and can be configured to proactively kill misbehaving processes instead of just letting the kernel OOM killer handle it. The major reason is time to recovery: a misbehaving process can cause a system to be so far under pressure that the kernel OOM killer will take a long time to flush things out, but a userspace component can respond in advance with more configurable rules (and more flexibility, since the kernel doesn't believe you're at capacity yet).
- danobi 6y ago
  Yes, exactly. > It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd Yep, I authored the original standalone oomd (along with many others' help) and Anita has been working on systemd-oomd. There's plans to converge and simplify everything that's been learned from oomd into systemd-oomd so the community can benefit from all our experiments.

iio7 6y ago

Could they maybe start handling the 1400+ bugs that has been a part of systemd for such a long time (some unresolved since 2015) rather than keep adding and adding and adding and adding code!

jbverschoor 6y ago
Feel free to contribute to open source projects!
jabiko 6y ago
There are a lot of open issues but you are a bit unfair in calling them bugs. If you filter out the RFEs (Requests For Enhancement) you find 617 issues. If you filter for only issues labeled as a bug you get 97 results.
- stonogo 6y ago
  OK, but they don't always label bugs that way (example: systemd/#5616) and the bugs that are labeled can get pretty old (systemd/#3700). Furthermore a lot of RFEs are really just disguised bug reports (systemd/#5917 is just an RFE rephrasing of system/#3700). In my experience, unless you can get Red Hat to care about patching a specific bug, you can rely on opened bugs to stay open.
  - viraptor 6y ago
    I didn't dig into others, but: > don't always label bugs that way (example: systemd/#5616) Nobody figured out if that issue is in logind or X yet. They did not close it so it's not like they say it can't possibly be on systemd side. (typical Lennart comments aside)
zokier 6y ago
People add features they need, and fix bugs that impact them. Scratching your own itch is the fundamental principle in open source. I recommend you to do the same.

znpy 6y ago

I have some questions. I started reading about systemd-oomd, then followed the link to its manpage (at https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.html https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.htm...) then followed a link from there to this page: "In defence of swap: common misconceptions" at https://chrisdown.name/2018/01/02/in-defence-of-swap.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html). The first line of the tl;dr is: "Having swap is a reasonably important part of a well functioning system. Without it, sane memory management becomes harder to achieve." Now, afaik linux as a kernel is pretty much designed to have swap memory and really not meant to be ran without it. Except disabling swap is required to run kubernetes, so much so that the kubelet will plain refuse to start if it detects swap memory enabled. Why?

geofft 6y ago
This is one of the primary reasons the Kubernetes folks are working on letting you run with swap! See recent discussion in https://github.com/kubernetes/kubernetes/issues/53533 https://github.com/kubernetes/kubernetes/issues/53533 . The historic reason Kubernetes didn't let you run with swap is that it's complicated from a resource management perspective - it's not clear whether each pod should be requesting some amount of swap the same way it requests some amount of RAM, and also the container runtimes didn't really have support for that (largely because you need cgroupv2 to have a hope of that sort of per-cgroup swap resource control working at all). But it's not an insurmountable problem, and it sounds from that ticket like they recognize that letting systems have swap enabled for the sake of a userspace oomd is an important use case.
xyzzy_plugh 6y ago
Why is Linux not meant to be ran without swap? In 2021? I've never heard of this. I've operated massive clusters of thousands of hosts with no swap enabled with zero hiccups. Swap comes with a lot of caveats -- when a performance-critical process begins swapping it can on occasion be more useful to just let it OOM instead. My personal desktop has 64GB of memory, with no swap enabled. Why would I want swap it I don't need more than that?
- 6y ago

diegocg 6y ago

If you want to understand why a oomd daemon is necessary and oom alone is not enough, you might be interested in this talk from FB "Linux memory management at scale" https://youtube.com/watch?v=cSJFLBJusVY https://youtube.com/watch?v=cSJFLBJusVY

Foxboron 6y ago
The finished talk with a (short) Q&A can be also be found. https://media.ccc.de/v/arch-conf-online-2020-6390-linux-memory-management-at-scale https://media.ccc.de/v/arch-conf-online-2020-6390-linux-memo... Q&A Questions: https://gitlab.archlinux.org/archlinux/conf-files/-/blob/master/2020/archconf/talks/Linux%20memory%20management%20at%20scale/questions.md https://gitlab.archlinux.org/archlinux/conf-files/-/blob/mas...
noobermin 6y ago
Can anyone provide a summary or short set of reasons? Proof by link to 40 minute video doesn't feel satisfactory.
- IshKebab 6y ago
  I mean, picking a process to kill at random is obviously a crap solution. Windows has done better than that for decades.

wooptoo 6y ago

They missed the opportunity to call it systemd-doom.

hhh 6y ago
systemd-oom

Klwohu 6y ago

That change log is HUGE and it’s the main reason we don’t use systemd. Creeping featurism isn’t good in your OS when you need things to be consistent and work the same every time. Systemd has a lot of state.

greyw 6y ago
Who is we? I use systemd on the operating systems I use (debian, centos and opensuse)
- Klwohu 6y ago
  Our organization. It doesn’t make sense to rely on software which grows to consume all available niches. Systemd is a perfect example of this kind of software. I don’t wish to have to ascertain what new features it’s reimplemented, sometimes in ways which are not POSIX compliant, every time there’s an update.
  - esarbe 6y ago
    Do I guess correctly that your organization doesn't value clean services initialization, solid services dependencies management and reliable log handling? Well, there must be room for such organizations too. It's a colorful world after all.
    - Klwohu 6y ago
      No, we get all of that with time-worn traditional methods which work well, are documented properly, and conform to standards. I’m not interested in beta testing Red Hat’s replacement for Linux.
dgellow 6y ago
I'm very happily using systemd since a bit less than a decade now. It's fantastic to have a common standardized way to manage your services and jobs that doesn't rely on a fragile set of scripts, and unified logs that can be easily queried and exported to a machine readable format.

p4cmanus3r 6y ago

Am I the only one excited about support for luks via TPM?

The_rationalist 6y ago

How will systemd-oomd communicate to the user? I was using https://github.com/hakavlad/nohang https://github.com/hakavlad/nohang And it sent notification signaling to save your work before the application X will be killed. (I always wanted a way to click somewhere on the notification to prevent nohand from killing it when unwanted) Also nohang use PSI data does oomd does it too? Finally the author of nohang is working on arguably superior solutions: https://github.com/hakavlad/prelockd https://github.com/hakavlad/prelockd https://github.com/hakavlad/memavaild https://github.com/hakavlad/memavaild https://github.com/hakavlad/le9-patch https://github.com/hakavlad/le9-patch It's unfortunate that systemd has chosen to integrate an inferior solution

flippinburgers 6y ago

Systemd is such a wonderful example of "if I didn't develop it, it isn't good enough."