Description of problem: I'm running my WM via `exec env $(systemctl --user show-environment) dbus-run-session -- sway` in console without any display manager and ``` Feb 28 19:57:37 ojab-notebook systemd-oomd[903]: Swap used (7432306688) / total (8229220352) is more than 90.00% Feb 28 19:57:37 ojab-notebook systemd-logind[1025]: Session 1 logged out. Waiting for processes to exit. Feb 28 19:57:37 ojab-notebook systemd[1]: session-1.scope: systemd-oomd killed 514 process(es) in this unit. Feb 28 19:57:37 ojab-notebook systemd[1]: getty: Deactivated successfully. ``` oomd kills the whole session instead of being more selective, which is not very handy for a laptop with the single purpose of running user session. Version-Release number of selected component (if applicable): Installed Packages Name : systemd Version : 248~rc2 Release : 1.fc34 Architecture : x86_64 Name : systemd-oomd-defaults Version : 248~rc2 Release : 1.fc34 Architecture : x86_64 How reproducible: Three times already and I don't see any other systemd-oomd actions (`earlyoom` killed firefox cnontent processes previously and I saw it), so I suppose always? Steps to Reproduce: 1. Start user session as described above 2. Fill the memory with some stuff Actual results: The session is killed Expected results: Some memory-hungry processes like browser is killed and session with WM still runs. Additional info:
It sounds like sway doesn't separate applications into their own cgroups as KDE and GNOME do; this is a prerequisite for ideal operation. Per the feedback section in https://fedoraproject.org/wiki/Changes/EnableSystemdOomd you can spawn applications yourself into separate cgroups using `systemd-run` or you can opt out of the systemd-oomd policy by removing the systemd-oomd-defaults.
So basically systemd-oomd will kill the whole session in case of memory pressure or low memory for anyone not using GNOME/KDE and it will disable earlyoom if it was configured? IMHO it's not ideal and quite unexpected.
I've filed an RFE for sway to organize processes into cgroups (https://bugzilla.redhat.com/show_bug.cgi?id=1935923). The EarlyOOM package is still available, it just isn't installed by default. If cgroups end up not being supported in sway you can opt out of systemd-oomd and use EarlyOOM.
Thanks. I already configured memory-killers as they were before, but 1. While I knew that systemd-oomd would be enabled in f34, it was unexpected to have earlyoom (potentially with it's own non-default settings) replaced by it. I understand that having two userspace oom-killers is not ideal and having default/unified system services on more setups is desired (I was planning to switch to systemd-oomd), but silently disabling manually installed/configured OOM handler is not good. 2. The session is killed without any notification pre/post kill. For me it looked like a `sway` bug (segfault or something) until I looked into `journalctl`, but I suppose that average cinnamon/mate/xfce/[pick any user-friendly DE except GNOME/KDE] user will not look into `journalctl` and just think `Oh well, fedora is just crashing sometimes`. So while I agree that cgroups are the proper way forward to handle OOMs, I'm not sure that we're ready for that for workstation usage [except GNOME/KDE?]. `sway` is certainly affected, but I assume that official desktop spins [based on https://spins.fedoraproject.org/], i. e. XFCE, LXQT, MATE-Compiz, Cinnamon, LXDE, SOAS (wtf is that) and i3 (new for f34) should be tested/covered first.
It looks like sway specifically should get sorted out in #1932728. As for other DEs, as discussed in the Change it was decided to enable this by default to minimize fragmentation, and leaving the choice to the DEs to opt out of oomd if needed (https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Should_spins_that_don.27t_put_processes_in_separate_cgroups_be_excluded_from_this_change.3F). I expect the upcoming test day (https://fedoraproject.org/wiki/Test_Day:2021-03-18_Systemd-OOMd_Test_Week) will help flush out potential issues as well.
Note: I've reassigned this to systemd, as oomd is the standalone version of oomd, which is unrelated to systemd-oomd itself.
I'll reassign this to sway, it needs to be handled there somehow. Until 1935923 is done, some docs to disable systemd-oomd and enable earlyoom might be appropriate. I don't think we can handle this meaningfully on the systemd side, since we don't really know too much about various guis.
I think this is not a bug of systemd-oomd - it's just a wrong tool selection. If your DE is XFce (or Mate, LXDE etc) - use alternative killers. If you need userspace OOM killer with PSI support but your DE doesn't launch apps in separate cgroups you could use nohang-desktop (which supports PSI and doesn't kill the whole session).
JFYI: cgroups support already requested for i3/Sway https://github.com/i3/i3/issues/4298
FYI i3 and sway are different projects. AFAICT this has not been reported to sway: https://github.com/swaywm/sway/issues
FYI #2. Quote from Sway project: > We are not accepting any new window management features unless they get implemented by i3.
Same result with F34 XFCE: [ 1448.161951] systemd-oomd[563]: Swap used (3865575424) / total (4115656704) is more than 90.00% [ 1452.012366] polkitd[652]: Unregistered Authentication Agent for unix-session:6 (system bus name :1.139, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf8) (disconnected from bus) [ 1452.013904] at-spi2-registryd[3882]: X connection to :0 broken (explicit kill or server shutdown). [ 1452.355238] systemd[1]: session-6.scope: systemd-oomd killed 82 process(es) in this unit. [ 1452.357987] systemd[1]: session-6.scope: Deactivated successfully. [ 1452.358238] systemd[1]: session-6.scope: Consumed 20.134s CPU time. [ 1452.358524] systemd-logind[675]: Session 6 logged out. Waiting for processes to exit. [ 1452.359377] systemd-logind[675]: Removed session 6. [ 1452.359533] unknown[3884]: xfce4-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. [ 1452.359837] systemd[909]: dbus-:1.2-org.xfce.ScreenSaver: Main process exited, code=exited, status=1/FAILURE [ 1452.360373] systemd[909]: dbus-:1.2-org.xfce.ScreenSaver: Failed with result 'exit-code'. [ 1452.360506] systemd[909]: dbus-:1.26-org.a11y.atspi.Registry: Main process exited, code=exited, status=1/FAILURE [ 1452.360638] systemd[909]: dbus-:1.26-org.a11y.atspi.Registry: Failed with result 'exit-code'. [ 1456.406449] audit[4334]: CRED_ACQ pid=4334 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_permit acct="lightdm" exe="/usr/sbin/lightdm" hostname=? addr=? terminal=:0 res=success' [ 1456.422679] lightdm[4334]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=983) by (uid=0) [ 1456.604325] systemd-logind[675]: New session c3 of user lightdm. [ 1456.611381] systemd[1]: Created slice User Slice of UID 983. And high CPU usage: 0.7-1%.
And also there is no systemd-oomd entries in the journal except this one: [ 1448.161951] systemd-oomd[563]: Swap used (3865575424) / total (4115656704) is more than 90.00%
(In reply to hakavlad from comment #13) > And also there is no systemd-oomd entries in the journal except this one: > > [ 1448.161951] systemd-oomd[563]: Swap used (3865575424) / total > (4115656704) is more than 90.00% The relevant journal line in your case was "[ 1452.355238] systemd[1]: session-6.scope: systemd-oomd killed 82 process(es) in this unit.". There is a "ManagedOOMPreference=avoid" option you can set on the session-.scope so it's less likely to be targeted, but I think you'll want to file a separate RFE for XFCE if it's not separating processes out from from session-.scope.
Just a me too: the whole X session on my primary workstation, including an on-going 3D print (about 4 hours out of 12), has been killed by systemd-oomd. The root cause was that I tried to recompile Ceph, and the C++ compiler took more memory than expected. Killing the whole user session on the OOM condition is not very helpful. It would be better to let the kernel OOM killer kick in, and kill some isolated process instead of the whole session on a single-user workstation, where there is nothing more important there apart from that very session. So far I disabled systemd-oomd altogether, but I think this is a misfeature, which should have different default configuration.
(In reply to Jan "Yenya" Kasprzak from comment #15) > So far I disabled systemd-oomd altogether, but I think this is a misfeature, > which should have different default configuration. As previously explained multiple times up above, if your desktop does not separate processes into cgroups, you *must not use systemd-oomd* because it will kill your entire desktop session. That's not a misfeature or a design mistake in systemd. Desktops either need to be updated to be smarter and use cgroups, or ensure systemd-oomd is not used. So incompatible Fedora spins should *not* install the systemd-oomd-defaults. Problem is it is included in the core comps group, which means it gets installed for all spins. That seems OK, because it's definitely wanted on servers and for major desktops (at least both GNOME and KDE), but for the spins where this is problematic, maybe desktops could add a Conflicts: to its spec to avoid this. E.g. sway could Conflicts: systemd-oomd-defaults. I think that would prevent it from getting installed. Or maybe I'm wrong and it would just cause a compose failure. I dunno.
As previously explained multiple times up above, there are cases when there is no spin. You just install default fedora with gnome and install whatever you want to use on top of it. And you're getting systemd-oomd that kills the whole session which looks like DE/WM/whatever crashing, because there is no indication that it's [pre-]oom. Every single user above says `So far I disabled systemd-oomd altogether` or something similar, it's just a couple of users that encountered this _and_ found the root cause. How many users just have crashing fedora installs or not reporting here — who knows? I completely understand POV `we want systemd-oomd in the next rhel`, but please don't `use non-existant spin` and `please know that fedora upgrade will kill your whole session and proactively fight that`, because it's not really `distro for people` stance. It's not user-friendly behavior and even with ``` set $term systemd-run --user --scope foot set $menu systemd-run --user --scope bemenu-run ``` in sway config it's worse experience that earlyoom gives me, so I don't see how `systemd-oomd` is good for desktop. It's just not thoughtfully thought decision that works fine only for a subset of users and you're trying to blame users for that. (sorry for passive/not passive aggressiveness, I'm not really polite lately due to personal reasons)
The decision has been made and the caveats are well known. It is very unlikely that this is going to be reconsidered. This really isn't about RHEL, it is all about getting things right and picking the superior solution. DE's will update eventually. The major ones have, the others will hopefully follow soon. And I also expect more terminals will learn to put each tab into a separate cgroup.
> DE's will update eventually. The major ones have, the others will hopefully follow soon. > And I also expect more terminals will learn to put each tab into a separate cgroup. Well, until they do, the current behaviour of Fedora is a bug and should be fixed. And ojab is right - it is not whether the user uses spin X or Y. FWIW, I use Fedora upgraded from maybe F16 on, and on another desktop I use Fedora Server with XFCE desktop installed on top of it. I think Fedora should be reconfigured to run systemd-oomd _only_ for GNOME sessions.
>it is all about getting things right and picking the superior solution. >And I also expect more terminals will learn to put each tab into a separate cgroup. and also browsers to put tabs into different cgroups, I guess, so only a couple of tabs are killed with option to restore them instantly instead of restarting the whole browser? earlyoom does this for me right now, not sure what `superior` is except `in systemd out of the box` then. I completely understand that cgroups technically give superior scope/granularity in theory, but unless _all_ software uses them out of the box — it looks like `microkernel is superior`. Sounds good, doesn't work. Don't take me wrong, I have systemd-oomd disabled and earlyoom enabled for a while, it works for me and I love fedora, it's just one of the things that is counterintuitive and not so easily discovered. It's not about me here, it's about general fedora usability for non-default-gnome-person.
Also, data point: ``` $ journalctl | grep systemd-oomd | grep -c Killed 116 ``` while I was trying to actually use systemd-oomd. I hope that anyone commenting here is actually using this piece of software.
Sorry for using this report but it seems that MATE desktop is also affected by systemd-oomd feature, btw. i received the report https://bugzilla.redhat.com/show_bug.cgi?id=2068699 I don't think that mate upstream will support cgroups in the next time so i want to disable systemd-oomd for Mate desktop spin. Can give me please some assistance? Removing systemd-oomd-defaults from spin kickstart file and installing earlyoom is simple, but how can i enable earlyoom systemd unit with a spin kickstart file or with an update in general for Mate?
(In reply to Wolfgang Ulbrich from comment #22) > Removing systemd-oomd-defaults from spin kickstart file and installing > earlyoom is simple, but how can i enable earlyoom systemd unit with a spin > kickstart file or with an update in general for Mate? Hi, your spin can install a service preset into %{_prefix}/lib/systemd/system-preset/ that enables earlyoom. See the fedora-release package https://src.fedoraproject.org/rpms/fedora-release/tree/rawhide for example of how to do this.
Thx, so a 80-mate-compiz.preset needs to be include in fedora-release package or is it possible to use my own main package for configurations?
I think you should create a new package for your spin's presets. I'm surprised you don't have one already: these are useful to have.
I like how you assume everyone runs a DE and not just a window manager. I have a fvwm2 config I've been updating since the late 90s, where I was using it on redhat 5 (not rhel). So systemd has a shiny new toy that works with your other shiny new toys and now you've broken the system because I use "exec()" to run programs instead some magic systemd way, so instead of whatever app had runaway with my memory, I come back to my desk being logged out, and trying to figure out what had happened. So the *workaround* for this is EITHER disable systemd-oomd unless you are using KDE or GNOME. or update every tool that uses "exec" to use "systemd-run ....". This is not user-friendly.
Please stop spamming here. This is a bug report for sway.
Michael, if it is so, then the bug should be reclassified as systemd bug, lightdm bug, Fedora bug, or whatever. FWIW, I have been biten by this, even though I don't have sway installed at all, and I use stock Fedora (server), upgraded since F16 or so, with XFCE desktop on top of it. The problem is, that systemd-oomd is errorneously enabled even for desktop sessions, which use plain execve(2) for starting user applications. For these sessions, systemd-oomd kills the whole session, which makes things way worse than either keeping the system swap-trashing to death, or waiting for stock kernel OOM handler to chime in.
As a bugreporter — it's not about sway, sway is used just as a reproducer.
(In reply to Jan "Yenya" Kasprzak from comment #28) > The problem is, that systemd-oomd is errorneously enabled even for desktop sessions, which use plain execve(2) for starting user applications Again, this is just configuration error. If you're using a Fedora spin, your spin maintainer should have disabled systemd-oomd for you. This change was messaged very prominently via the Fedora change process to ensure spin maintainers knew that they need to disable systemd-oomd if they're not ready for it. If you're not using a Fedora spin and are instead doing something custom on your own, then it's your job to disable it manually. Nowadays desktops are expected to segregate processes into cgroups: this is not only important for protecting your desktop from systemd-oomd, it also allows desktops to perform resource control. It's the only way to keep your desktop responsive under heavy I/O load, for example. We know that many desktops are not ready for this yet, and that's fine, but you'll just need to disable systemd-oomd in the meantime. (In reply to ojab from comment #29) > As a bugreporter — it's not about sway, sway is used just as a reproducer. OK, in that case, I've reassigned the bug back to systemd-oomd, and closed it since systemd-oomd is working exactly as designed. Feel free to report separate bugs against other spins if desired. Users: please disable systemd-oomd if your desktop does not use cgroups. If you are using a Fedora spin and feel it should have been done for you, then please report a bug to the spin maintainers. Spin maintainers: please ensure systemd-oomd is not enabled by default for your users if your desktop isn't ready for it. The best way to do this is to ship a preset that disables this service. Don't forget to ensure it takes precedence over the default presets.
For more specific instructions, see comment #23. Be sure to test to ensure your preset wins out over the Fedora defaults.
The problem with solution in comment #23 is that it is - as far as I understand it - global. UNIX is a multi-user system, and it is quite common here to have a single system used by multiple users, each with his own prefered desktop environment. The correct solution would be to enable oomd to kill the whole session only for desktop environments which put individual processes to dedicated cgroups. Or, is multi-user Fedora no longer supported configuration?
Thinking about the issue further - does this mean that if I for example start Firefox (or another big process) from the command line instead of from whatever panel the desktop environment provides, it would behave differently, being in a cgroup together with other processes started from that terminal? The more I think about how systemd-oomd is expected to work in the desktop environment, the more misdesigned it looks.
Michael, thank you for writing this up so clearly. > UNIX is a multi-user system, and it is quite common here to have a single system used by multiple users, each with his own prefered desktop environment. In those cases, it's up to the admin to set up the machine as appropriate. As was said before (multiple times), just disable systemd-oomd such cases. > I for example start Firefox (or another big process) from the command line instead of from whatever panel the desktop environment provides, it would behave differently, being in a cgroup together with other processes started from that terminal? Yes, it'd be in one cgroup and it'd be killed along with the whole terminal tab on oom. We probably should try to handle this better, but it's how systemd-oomd was designed, so it's a missing feature rather than a bug. If you are starting firefox like this, and hitting triggering oom conditions with it, there are two choices: - wrap the command in something systemd-run to get a separate scope - not use systemd-oomd.
(In reply to Jan "Yenya" Kasprzak from comment #33) > Thinking about the issue further - does this mean that if I for example > start Firefox (or another big process) from the command line instead of from > whatever panel the desktop environment provides, it would behave > differently, being in a cgroup together with other processes started from > that terminal? The more I think about how systemd-oomd is expected to work > in the desktop environment, the more misdesigned it looks. If your terminal is smart like gnome-terminal or gnome-console, then either each command runs in its own cgroup. I believe KDE's Konsole does this too, but not certain. For example: │ │ │ ├─vte-spawn-309ce45c-15d4-4ff5-ad88-ceccc965b2ea.scope (#13746) │ │ │ │ ├─25136 /bin/bash │ │ │ │ ├─25182 systemd-cgls │ │ │ │ └─25183 less One vte-spawn scope per command. If your terminal is not smart enough to do this, you should probably NOT enable systemd-oomd! This really makes sense: it allows terminals to use cgroups to tell systemd what should die together and what should not. It works for applications too, e.g. I have an experimental patch where WebKit uses systemd-run to launch subprocesses (currently we rely on uresourced to handle this; make sure you have uresourced running if you use a web browser!). systemd-oomd is enabled by default in Fedora because (a) it's good for servers, (b) it's good for Fedora Workstation, and (c) it's good for Fedora KDE spin. For other desktops and other terminals, you really need to think whether it makes sense for you or not. You'll have a bad experience unless both desktop and terminal are prepared.
> (In reply to Michael Catanzaro from comment #35) > (In reply to Jan "Yenya" Kasprzak from comment #33) > > Thinking about the issue further - does this mean that if I for example > > start Firefox (or another big process) from the command line instead of from > > whatever panel the desktop environment provides, it would behave > > differently, being in a cgroup together with other processes started from > > that terminal? The more I think about how systemd-oomd is expected to work > > in the desktop environment, the more misdesigned it looks. > > If your terminal is smart like gnome-terminal or gnome-console, then either > each command runs in its own cgroup. Unfortunately, if your gnome-terminal starts at login and runs bash and your .bashrc starts tmux (if not started already) and tmux starts everything else and then you compile something in a tmux pane...systemd-oomd kills everything: ``` May 03 14:36:49 X systemd[1982]: vte-spawn-0cffb3a1-05b8-4288-a7ac-e5607df89a2a.scope: systemd-oomd killed 184 process(es) in this unit. May 03 14:36:49 X systemd-oomd[925214]: Killed /user.slice/user-8001.slice/user/app.slice/app-org.gnome.Terminal.slice/vte-spawn-0cffb3a1-05> May 03 14:36:50 X systemd[1982]: vte-spawn-0cffb3a1-05b8-4288-a7ac-e5607df89a2a.scope: Consumed 6h 24min 54.762s CPU time. ``` > This really makes sense: it allows terminals to use cgroups to tell systemd > what should die together and what should not. So is my problem gnome-terminal, or tmux? I understand what you're saying about how cgroups *should* be used...
You want to report a bug to tmux. It should probably learn to move processes it creates into cgroups. If it doesn't create cgroups, then everything will get killed together. Simple as that.
(In reply to Michael Catanzaro from comment #25) > I think you should create a new package for your spin's presets. I'm > surprised you don't have one already: these are useful to have. After removing systemd-oomd-defaults from MATE Desktop with mate-desktop-1.26.0-5.fc36 using ``` Recommends: earlyoom Conflicts: systemd-oomd-defaults ``` it turns out that user runs in another problem when using `dnf groupinstall mate-desktop-environment` command. ``` [root@f36 rave]# dnf groupinstall mate-desktop-environment --disablerepo results Last metadata expiration check: 0:16:37 ago on Mon May 9 20:53:45 2022. No match for group package "xorg-x11-drv-armsoc" Dependencies resolved. Problem: package mate-desktop-1.26.0-5.fc36.x86_64 requires mate-desktop-configs = 1.26.0-5.fc36, but none of the providers can be installed - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.3-8.fc36.noarch - cannot install the best candidate for the job - conflicting requests ================================================================================ Package Arch Version Repository Size ================================================================================ Installing group/module packages: systemd-oomd-defaults noarch 250.3-8.fc36 fedora 27 k Downgrading: mate-desktop x86_64 1.26.0-3.fc36 fedora 82 k mate-desktop-configs noarch 1.26.0-3.fc36 fedora 10 k mate-desktop-libs x86_64 1.26.0-3.fc36 fedora 644 k Installing Environment Groups: MATE Desktop Installing Groups: Administration Tools base-x Core Dial-up Networking Support Fonts Guest Desktop Agents Hardware Support Input Methods MATE Multimedia Common NetworkManager Submodules Printing Support Standard Transaction Summary ================================================================================ Install 1 Package Downgrade 3 Packages ``` This is because systemd-oomd-defaults is in comps core group marked as default. ``` <group> <id>core</id> <_name>Core</_name> <_description>Smallest possible installation</_description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq type="mandatory">audit</packagereq> <packagereq type="mandatory">basesystem</packagereq> <cut> <packagereq type="default">systemd-oomd-defaults</packagereq> <cut> </packagelist> </group> ``` Here a user reported the issue https://bugzilla.redhat.com/show_bug.cgi?id=2078108#c4 What can i do to fix the problem? IHMO systemd-oomd-defaults should be optional in comps core group, otherwise the option in wiki page for not using systemd-oomd for spins doesn`t work. https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Should_spins_that_don.27t_put_processes_in_separate_cgroups_be_excluded_from_this_change.3F Sorry, for using this report again. Should we opening another for this problem?
(In reply to Michael Catanzaro from comment #37) > You want to report a bug to tmux. It should probably learn to move processes > it creates into cgroups. If it doesn't create cgroups, then everything will > get killed together. Simple as that. Thanks -- will do. By any chance, would you be able to point me to code in gnome-terminal that does it? Perhaps this: https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/systemd.cc ...? It looks like tmux already sort of tried, but maybe it got misunderstood :( https://github.com/tmux/tmux/issues/3024 (mentioned as related to https://github.com/tmux/tmux/issues/428 but doesn't seem to be). Appreciate the help; any other tips, would be appreciated too. Just had this happen again today (oomd killed whole tmux session).
(In reply to Wolfgang Ulbrich from comment #38) > Sorry, for using this report again. Should we opening another for this > problem? Hmmm... I suppose. I do not know what to do about this. (In reply to Martin Dengler from comment #39) > Thanks -- will do. By any chance, would you be able to point me to code in > gnome-terminal that does it? Perhaps this: > https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/systemd.cc ...? Yes indeed, you found it. > It looks like tmux already sort of tried, but maybe it got misunderstood :( > https://github.com/tmux/tmux/issues/3024 (mentioned as related to > https://github.com/tmux/tmux/issues/428 but doesn't seem to be). Benjamin (who created that tmux#3024) is actually the best person to talk to about this.
(In reply to Michael Catanzaro from comment #40) > (In reply to Martin Dengler from comment #39) > > Thanks -- will do. By any chance, would you be able to point me to code in > > gnome-terminal that does it? Perhaps this: > > https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/systemd.cc ...? > > Yes indeed, you found it. Thanks. https://github.com/tmux/tmux/issues/3024#issuecomment-1004166931 alludes to a way to do this "entirely without dbus", which sounds even lighter-weight. > > It looks like tmux already sort of tried, but maybe it got misunderstood :( > > https://github.com/tmux/tmux/issues/3024 (mentioned as related to > > https://github.com/tmux/tmux/issues/428 but doesn't seem to be). > > Benjamin (who created that tmux#3024) is actually the best person to talk to > about this. Thanks. I remember Benjamin from OLPC/Sugarlabs. I opened https://github.com/tmux/tmux/issues/3183 and hopefully can help. I still can't find an easy way to move processes around without ~/.config unit files, so looking forward to learning more about this. Is there a place more appropriate for an ongoing discussion (#fedora?), so I don't spam this bug report?
https://github.com/tmux/tmux/issues/3183 seems like a good place to discuss!
After reboot, systemd-oomd.service is started on login as a dependency of "user@.service" even though it is "disabled". Does anyone have a full workaround for disabling this service?
Oh, that's because /usr/lib/systemd/system/user@.service.d/10-oomd-user-service-defaults.conf configures ManagedOOMMemoryPressure= which causes oomd to be enabled automatically. If you can't uninstall systemd-oomd-defaults-250.3-8.fc36.noarch, then do sudo mkdir -p /etc/systemd/system/user@.service.d/ sudo ln -s /dev/null /etc/systemd/system/user@.service.d/10-oomd-user-service-defaults.conf
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days