Proposed as a Blocker for 44-final by Fedora user ngompa using the blocker tracking app because:

 This is a potential violation of the criterion stating "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."

oomd is enabled in /usr/lib/systemd/system-preset/90-default.preset , which is part of fedora-release-common . presets get applied at install time...I don't remember off the top of my head when else (if ever) they get applied...

AGREED Delayed Decision

Discussed at the 2026-03-30 (blocker / freeze exception) review meeting:

There seems to be a lot of uncertainty about this ATM. We will wait for more info from the reporter, and possibly some independent re-testing of clean f42/f43 installs and upgrades, to make the determination.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-03-30/f44-blocker-review.2026-03-30-16.00.log.txt

(In reply to Adam Williamson from comment #2)
> oomd is enabled in /usr/lib/systemd/system-preset/90-default.preset , which
> is part of fedora-release-common . presets get applied at install time...I
> don't remember off the top of my head when else (if ever) they get applied...

The file is there and oomd is present as enabled as of fedora-release-common-0:44-0.15.

I see only few records in one of my vm regarding the oomd being updated, but most concerning there is not a single record for it starting:

```
$ journalctl -u systemd-oomd
-- No entries --
```

While on my machine, where I enabled it manually yesterday:

```
$ journalctl -u systemd-oomd
Mär 30 11:48:31 wasp-9950x3d systemd[1]: Starting systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer...
Mär 30 11:48:31 wasp-9950x3d systemd[1]: Started systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer.
...
```

Same on all other machines, where oomd is disabled, it was never enabled (judging by the missing entries in journalctl), two machines that has it enabled, has it enabled for a long time.

I use Fedora KDE for a lot of releases by now, always doing distro-upgrade.
Currently I'm on F44 as see below:

Operating System: Fedora Linux 44
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
Kernel Version: 6.19.10-300.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700U with Radeon Graphics
Memory: 24 GiB of RAM (22.8 GiB usable)
Graphics Processor: AMD Radeon Graphics

and this is the systemctl status output:

geraldo@losartana ~> systemctl status systemd-oomd.service
● systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2026-04-01 00:12:54 -03; 1h 8min ago
 Invocation: 981e220fa7984e9abe832c4ff0a6ac27
TriggeredBy: ● systemd-oomd.socket
       Docs: man:systemd-oomd.service(8)
             man:org.freedesktop.oom1(5)
   Main PID: 1070 (systemd-oomd)
     Status: "Processing requests..."
      Tasks: 1 (limit: 27938)
     Memory: 2M (min: 64M, low: 64M, peak: 4.6M)
        CPU: 6.773s
     CGroup: /system.slice/systemd-oomd.service
             └─1070 /usr/lib/systemd/systemd-oomd

abr 01 00:12:53 losartana systemd[1]: Starting systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer...
abr 01 00:12:54 losartana systemd[1]: Started systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer.

I don't know how and what to check if it was applied. I have a rawhide installation that also by the looks of it never had it enabled. I'm wondering, could it (enabling the service) be blocked by selinux for example? Because the current rawhide installation I have is swarmed by selinux alerts.

Created attachment 2135609 [details]
fresh out of install status

Okay, I've found an ISO I've used for the rawhide installation and the result is reproducible, if someone wants to check why it's not applied.

Fedora-KDE-Desktop-Live-Rawhide-20260106.n.0.x86_64.iso
sha256: 6c19d1d9e80482858a5285546d3b43e35a346e61efb30ccd9f8c24683f5d87df

I guess as of Jan 6th, it was basically a rebuild of F43, so it's still probably rooted somewhere there.

I've tried latest nightly of F44 today and it works as expected, so new F44 installation is of no concern as far as I can tell right now, but I'm still curious if there is a way to maybe do one time check if at least this particular service is enabled for upgrades?

I only found it because of a rough python script with a memory leak, otherwise I've been using my system for a year now without knowing.

There seems to be some confusion:
> 2. systemctl status systemd-oomd.service
...
> Actual Results:
> ○ systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket
>      Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.socket; disabled; preset: disabled)
>      Active: inactive (dead) since Mon 2026-03-30 14:32:08 CEST; 1s ago
...
> Expected Results:
> ● systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket
>      Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.socket; enabled; preset: disabled)
>      Active: active (running) since Mon 2026-03-30 14:32:42 CEST; 1s ago

Those results are not for the command shown. Also, the 'loaded' line
indicates that this stopped socket unit was running just a moment ago.

So we have a little ugliness here: systemd-oomd.service is enabled in presets,
and it has [Install] Also=systemd-oomd.socket, but systemd-oomd.socket is disabled
in presets, so depending on the installation order, we'll end up with systemd-oomd.socket
enabled or disabled. This ultimately doesn't matter much, because systemd-oomd.service
has Requires=systemd-oomd.socket, so when it is started, the socket will be started
too. The socket is used by user managers, which run later anyway.

We'll have to adjust the presets to enable the socket unit too, but I don't think
this is a cause of this bug.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> There seems to be some confusion:
> > 2. systemctl status systemd-oomd.service
> ...
> > Actual Results:
> > ○ systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket
> >      Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.socket; disabled; preset: disabled)
> >      Active: inactive (dead) since Mon 2026-03-30 14:32:08 CEST; 1s ago
> ...
> > Expected Results:
> > ● systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket
> >      Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.socket; enabled; preset: disabled)
> >      Active: active (running) since Mon 2026-03-30 14:32:42 CEST; 1s ago
> 
> Those results are not for the command shown. Also, the 'loaded' line
> indicates that this stopped socket unit was running just a moment ago.

Yes, that's correct, it was taken from my system *after* I've re-enabled the service and then stopped manually and tweaked it. The attached screenshot in my last message shows the actual right-post-install output.

> Fedora-KDE-Desktop-Live-Rawhide-20260106.n.0.x86_64.iso

That image is unforunately now gone from the server. I tried with the latest one (Fedora-KDE-Desktop-Live-Rawhide-20260406.n.0.x86_64.iso) and after installation, systemd-oomd.service is enabled and running.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #10)
> > Fedora-KDE-Desktop-Live-Rawhide-20260106.n.0.x86_64.iso
> 
> That image is unforunately now gone from the server. I tried with the latest
> one (Fedora-KDE-Desktop-Live-Rawhide-20260406.n.0.x86_64.iso) and after
> installation, systemd-oomd.service is enabled and running.

Here is my copy: https://e.pcloud.link/publink/show?code=XZJymvZ24sW3SU8bwV3fCHrHLQFOuIuvvuk if that helps. I already mentioned that latest version seems to work and new installations are of no concern, it's the upgrade path that bothers me.

FEDORA-2026-871e4e0fc3 (fedora-release-43-27) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-871e4e0fc3

Discussed at 2026-04-06 blocker review meeting: https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-06/f44-blocker-review.2026-04-06-16.00.html . Rejected as a blocker as it does not clearly violate any criteria: https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#System_services requires that all enabled services start correctly, not that all intended services be enabled. An intended service not being enabled might violate some other functional criterion, but this case does not appear to. An upgrade disabling a service that was previously enabled might possibly count as a violation, but that does not appear to be the case here.

Accepted as a freeze exception to allow the fairly clear fix to the presets to be included in F44 in case it helps avoid the problem in future. The FE is not read as applying to any attempt to fix this for existing installs with scriptlets, that seems too dangerous to attempt during freeze.

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

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

FEDORA-2026-871e4e0fc3 (fedora-release-43-27) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-3bd574e539 (fedora-release-44-17) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-3bd574e539

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

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

FEDORA-2026-3bd574e539 (fedora-release-44-17) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.