Bug 2078108

See https://bugzilla.redhat.com/show_bug.cgi?id=2068699
and https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Should_spins_that_don.27t_put_processes_in_separate_cgroups_be_excluded_from_this_change.3F
and https://bugzilla.redhat.com/show_bug.cgi?id=1933494
for more infos.
Using systemd-oomd is dangerous for mate-desktop because it can kill the whole X-session because of missing cgroups support.
When system runs out of memory X-session will be kiiled by systemd-oomd, reported by a users in reports.
Mate desktop will step back to original `earlyoom` memory management implementation, which was used before f34 in fedora.

So removing systemd-oomd-defaults will simply disable systemd-oomd unit, and earlyoom service will be installed by the update and is enabled by default.
I've tested the update process several times and it works smoothly.
Maybe a restart is needed.....

Don't worry, everything works as expected and like it should.
Sorry, there was no other way to revert systemd changes for f34.

I will leave this report open to inform other users.

Thanks so much for thed updated info!

Problem exists on F36 as well.

Again, please read previous postings.
There is no problem.
Mate desktop use earlyoom.

Link to the confirmed issue with MATE desktop: https://github.com/mate-desktop/mate-desktop/issues/519

(In reply to Wolfgang Ulbrich from comment #4)
> Again, please read previous postings.
> There is no problem.
> Mate desktop use earlyoom.

OK, well, after installing earlyoom, the command "dnf groupinstall mate-desktop-environment" STILL wants to install systemd-oomd-defaults and downgrade mate-desktop, mate-desktop-configs and mate-desktop-libs from 1.26.0-5.fc36 to 1.26.0-3.fc36. It's impossible to simultaneously have the mate-desktop-environment group fully installed (including systemd-oomd-defaults) AND have the latest version of all packages.

Can the mate-desktop-environment group be redefined so as to pull in earlyoom instead of systemd-oomd-defaults?

(In reply to Andre Robatino from comment #7)
> Can the mate-desktop-environment group be redefined so as to pull in
> earlyoom instead of systemd-oomd-defaults?

Thanks for reporting this. I never put systemd-oomd-defaults to mate-desktop-environment group for myself.
I will investigate.

*** Bug 2082901 has been marked as a duplicate of this bug. ***

I should mention that I periodically rerun the groupinstall command for all installed groups, since the group definitions can change. I don't remember exactly what happened, but I may have initially had earlyoom automatically installed, then after updating and running the groupinstall command again, noticed the conflict. Most people will only run the groupinstall command once and may not notice it.

systemd-oomd-defaults is in core comps group, ihmo systemd maintainer needs to change that.
https://pagure.io/fedora-comps/blob/main/f/comps-f36.xml.in#_640
But i posted it already in another report.
https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38
Maybe a serparate report against systemd helps?

(In reply to Wolfgang Ulbrich from comment #11)
> systemd-oomd-defaults is in core comps group, ihmo systemd maintainer needs
> to change that.
> https://pagure.io/fedora-comps/blob/main/f/comps-f36.xml.in#_640
> But i posted it already in another report.
> https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38
> Maybe a serparate report against systemd helps?

Comps is unfortunately maintained separately. Please open an issue (or a pull request) under the comps repo.

I don't know how to make this work. The docs say:
> 'optional' are not automatic but can be checked
> 'default' are, but can be unchecked in a gui tool

It seems 'default' is too much, but 'optional' not enough. So maybe it'd be necessary to move 'systemd-oomd-defaults'
out of @core into other top-level groups.

@Andre Robatino
Can you please file out another report against comps package group?
To get responsible maintainers involved.
And link it here.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #12)
> (In reply to Wolfgang Ulbrich from comment #11)
> 
> I don't know how to make this work. The docs say:
> > 'optional' are not automatic but can be checked
> > 'default' are, but can be unchecked in a gui tool
> 
> It seems 'default' is too much, but 'optional' not enough. So maybe it'd be
> necessary to move 'systemd-oomd-defaults'
> out of @core into other top-level groups.

Where can i find the docs about comps features?

(In reply to Wolfgang Ulbrich from comment #13)
> @Andre Robatino
> Can you please file out another report against comps package group?
> To get responsible maintainers involved.
> And link it here.

I'm sorry, I don't know how or where to do that. In https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38 you were able to exactly reproduce what I see, and you obviously understand it better.

https://pagure.io/fedora-comps/issues

(In reply to Andre Robatino from comment #14)
> (In reply to Wolfgang Ulbrich from comment #13)
> > @Andre Robatino
> > Can you please file out another report against comps package group?
> > To get responsible maintainers involved.
> > And link it here.
> 
> I'm sorry, I don't know how or where to do that. In
> https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38 you were able to
> exactly reproduce what I see, and you obviously understand it better.

You're using an email from fedoraproject.org and don't know to file out a new bugreport?

I am so sorry too, i am complete bussy with work, i do not have the time to do this very small work for you.
I mean you're are the person you like to do the groupinstall command very often.....

Ok, reassign this report to comps to fixing the remaining issue.

Dear, comps maintainer currently the groupinstall command generates a conflict betweeen mate-desktop-configs and systemd-oomd-defaults

```
[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>
```
What can i do to fix the problem?
IHMO systemd-oomd-defaults should be optional in comps core group or moved to another 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

https://pagure.io/fedora-comps/issue/737

Fixed in https://pagure.io/fedora-comps/pull-request/750

This does not seem to be fixed.  I am trying this on a freshly-upgraded F35->F36 system that doesn't have MATE and still getting the conflict error:

sudo dnf groupinstall "MATE Desktop" --best --allowerasing
Last metadata expiration check: 1:32:48 ago on Sat 17 Dec 2022 04:34:04 PM PST.
No match for group package "xorg-x11-drv-armsoc"
Error: 
 Problem: package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch
  - 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
  - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages)

I have another F35 system that already has MATE Desktop installed and I can't find a clean path to upgrade:

sudo dnf system-upgrade download --releasever=36
.
.
.
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 mate-desktop-configs              noarch 1.26.0-5.fc36           updates  11 k

sudo dnf system-upgrade download --releasever=36 --best --allowerasing
.
.
.
Error: 
 Problem 1: cannot install the best update candidate for package mate-desktop-configs-1.26.0-4.fc35.noarch
  - problem with installed package mate-desktop-configs-1.26.0-4.fc35.noarch
  - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch
  - cannot install the best candidate for the job
  - mate-desktop-configs-1.26.0-4.fc35.noarch does not belong to a distupgrade repository
 Problem 2: cannot install the best update candidate for package imsettings-gsettings-1.8.3-1.fc35.x86_64
  - problem with installed package imsettings-gsettings-1.8.3-1.fc35.x86_64
  - package imsettings-gsettings-1.8.3-6.fc36.x86_64 obsoletes imsettings-systemd < 1.8.3-6 provided by imsettings-systemd-1.8.3-2.fc36.x86_64
  - cannot install the best update candidate for package imsettings-systemd-1.8.3-1.fc35.x86_64
  - problem with installed package imsettings-systemd-1.8.3-1.fc35.x86_64
  - imsettings-systemd-1.8.3-1.fc35.x86_64 does not belong to a distupgrade repository
  - imsettings-gsettings-1.8.3-1.fc35.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

Confirmed still broken in F36 and F37:

 Problem 1: package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch
  - cannot install the best update candidate for package systemd-oomd-defaults-250.8-1.fc36.noarch
  - cannot install the best update candidate for package mate-desktop-configs-1.26.0-3.fc36.noarch
 Problem 2: problem with installed package systemd-oomd-defaults-250.8-1.fc36.noarch
  - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch
  - 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
  - cannot install the best update candidate for package mate-desktop-1.26.0-3.fc36.x86_64
==================================================================================================================================================================================
 Package                                            Architecture                         Version                                      Repository                             Size
==================================================================================================================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 mate-desktop-configs                               noarch                               1.26.0-5.fc36                                updates                                11 k
Skipping packages with broken dependencies:
 mate-desktop                                       x86_64                               1.26.0-5.fc36                                updates                                82 k

Transaction Summary
==================================================================================================================================================================================
Skip  2 Packages

The conflict with systemd-oom-defaults should likely just be removed.  mate-desktop-configs does not be marked as directly conflicting with systemd-oom-defaults.

One can used mate-desktop with systemd-oom or with earlyoom, or for that matter, no out-of-memory manager at all.  And that's just the run-time decision.  Whether either or both systemd-oom (and systemd-oom-defaults) and earlyoom packages are installed together also is not a problem by itself.  A system owner may choose to decide to run systemd-oom or earlyoom and may change that choice at any time as desired for particular situations.

I have read the various comments about experiences with systemd-oom killing more than it really needs to perhaps - entire desktop sessions (or tmux sessions) instead of killing whatever memory hog with finer granularity.  The desire to have improved out-of-memory handling is understandable.  And when MATE grows cgroup support, it may be a better experience with systemd-oom on the occasion that memory pressure necessitates OOM manager to take action.  But for one thing, it should be rare that OOM is needed - it should be the infrequent exception that a particular system is hitting OOM events regularly (if not it's a system configuration problem in most cases - or possibly a software bug with runaway memory consumption).  Examples of some reports of the problem: https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c22, https://www.reddit.com/r/Fedora/comments/u9xb1s/issue_having_matedesktop_conflicts_with/.

It's up to the system owner whether they choose to use systemd-oom or earlyoom or neither.  And they may have very good reasons for choosing one of those options.  It should not be up to the mate-desktop-configs package to dictate that choice. A recommendation is fine - as in the 'Recommends: earlyoom' clause currently in mate-desktop.spec. That recommendation makes sense at this time - until such time as MATE adds cgroup support to play better with systemd-oom.

But marking the systemd-oomd as a package installation conflict is the wrong scope for handling any issues with dueling OOM managers.  It just causes headaches and confusion for unsuspecting users who want to update their systems - and possibly results in decisions that should not be necessary, such as deleting MATE because of the headaches.

See the proposed pull request: https://src.fedoraproject.org/rpms/mate-desktop/pull-request/2

Changes to comps groups are only working for new released fedora versions started with rawhide.
So you will never see that change in f36.
After moving systemd-oom-defaults to supporting c-groups environments in comps with that commit https://pagure.io/fedora-comps/c/01ba068318ee0bd4f0cc5f5bff4f23c15cf95fd9?branch=main the situation is different.
But i agree to remove the conflict marker from spec file for f37/38 and rawhide. See this PR https://src.fedoraproject.org/rpms/mate-desktop/pull-request/2#
Now it's sure that a new MATE standard default installation comes without systemd-oom-defaults.

(In reply to Wolfgang Ulbrich from comment #23)
> Changes to comps groups are only working for new released fedora versions
> started with rawhide.
> So you will never see that change in f36.

I understand your remark.  I actually bumped into the dnf update problem (most recently) while belatedly updating an old f33 host to f34 (which from there will update to newer versions as local conditions dictate).  I know that an old problem going from f33 -> f34 is outside the scope of support, so I'm not too concerned about that.  The pull request is for newer supported fedora versions that can still potentially hit the dnf conflict.

> After moving systemd-oom-defaults to supporting c-groups environments in
> comps with that commit
> https://pagure.io/fedora-comps/c/
> 01ba068318ee0bd4f0cc5f5bff4f23c15cf95fd9?branch=main the situation is
> different.
> But i agree to remove the conflict marker from spec file for f37/38 and
> rawhide. See this PR
> https://src.fedoraproject.org/rpms/mate-desktop/pull-request/2#
> Now it's sure that a new MATE standard default installation comes without
> systemd-oom-defaults.

One problem is that there exist systems in the world that are more than just a "MATE standard default install".  We have systems where some users will use MATE, others might use XFCE or GNOME, etc., sometimes concurrently.  So moving systemd-oom-defaults out of the core comps group may not help avoid the dnf failure since dnf installing other desktop environment groups can still pull in systemd-oom-defaults.

Thanks for considering the removal of the conflict marker.  MATE just seems like the wrong scope in which to adjudicate OOM manager choices.

FEDORA-2023-2a193c0384 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a193c0384

FEDORA-2023-2a193c0384 has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a193c0384

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-82251ee7c9 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-82251ee7c9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-82251ee7c9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-82251ee7c9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-82251ee7c9

FEDORA-2023-82251ee7c9 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-82251ee7c9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-82251ee7c9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-82251ee7c9 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

I am thinking about to change `Recommends:  earlyoom` to `Recommends:  systemd-oomd-defaults` for f40, to get closer to common fedora.
In the end only one user was affected  by this issue and more users was to use systemd-oomd-defaults.
And it is possible to uninstall systemd-oomd-defaults after it was removed from core group.

(In reply to Wolfgang Ulbrich from comment #31)
> In the end only one user was affected  by this issue and more users was to
> use systemd-oomd-defaults.

It's not clear where that comment (only one user) comes from.  Just in this thread, more than one user spoke up who was affected.

As far as I can tell, MATE has not added cgroup support yet (although I may have missed it).

(In reply to John Hein from comment #32)
> (In reply to Wolfgang Ulbrich from comment #31)
> > In the end only one user was affected  by this issue and more users was to
> > use systemd-oomd-defaults.
> 
> It's not clear where that comment (only one user) comes from.  Just in this
> thread, more than one user spoke up who was affected.
> 
> As far as I can tell, MATE has not added cgroup support yet (although I may
> have missed it).

Please read careful posts.
In this report users like you complains only about the previous package conflict issues when updating.
In the other origin linked report only the reporter was affected.

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.