+1

Though not sure if we should enable this for example in i3 spin and others where apps are not properly put in their own cgroups.

+1

Though not sure if we should enable this for example in i3 spin and others where apps are not properly put in their own cgroups.

If oomd is a subpackage in systemd and excluded in a spin's kickstart, it can be globally enabled in presets while selectively removed from spins where appropriate. I think that's a reasonable way to opt-out if they want to.

I'd like to have answers / clarifications for two issues that have been raised on the devel list before I vote:

• Some desktop environments don't put applications into separate cgroups (AFAIK, only GNOME and KDE do that). Should other desktop-oriented Spins be excluded from this Change for now?

• There seemed to be concensus that it would be better to switch everybody from earlyoom to systemd-oomd, even on upgrade, to not fragment the Fedora install base. Will this happen or not? The proposal has not been updated.

+1

There's some details to be figured out, but nothing too onerous. I wouldn't be surprised if the opt-out/opt-in mechanisms will need to be adjusted a few times before we reach the final form, and I think it'd be beneficial to push this earlier rather than later to start gathering feedback.

I agree with @decathorpe here, might as well move everyone over to systemd-oomd on upgrade. And yeah, figuring out the details there may be a bit bumpy, but I think that's fine in rawhide.

+1

+1 here... yeah, Xfce/lxde/etc may need to opt out.

This was discussed in today's FESCo meeting:
AGREED: APPROVED (+6, 2, 0)

Also agreed in the meeting: systemd-oomd-defaults subpackage will be split out of the systemd subpackage.