I can't reproduce using the steps in the bug. I see less eventually getting killed.

FinalBlocker -1

I'm not seeing this using the reproducer from the bug with the 20240210.n.1 Workstation compose on a bare metal machine with 4 GB RAM either, or at least, I'm not seeing the system become unresponsive.

systemd-oomd does not appear to kill the less process though, it appears to be killed by the kernel oom killer.

With 20240210.n.1 Workstation on my bare metal test machine (Lenovo M53 with a i5-4570 CPU and 8GB) I opened three Firefox windows and 10 tabs in each with different websites. Then I opened three applications and system monitor all at the same time. I could only get the memory up to 7.3 GB. Nothing misbehaved and no messages. It just started using swap space.

Discussed during the 2024-02-12 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as we agreed this bug could do with further testing for a more complete understanding of whether systemd-oomd really isn't working at all, or is not kicking in in certain circumstances.

[0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-12/f40-blocker-review.2024-02-12-17.05.txt

at least, I'm not seeing the system become unresponsive.

Right, this is fairly random and depends a lot on the hardware in use. I'm running Fedora Asahi here and apparently their GPU driver can lock up quickly in out-of-memory situations, whereas the intel GPU driver seems to handle those situations a bit better and doesn't lock up.

Ultimately, from what I've heard, these lock-ups are somewhat unavoidable in really bad out-of-memory situations, and the kernel OOM killer is known to kick in too late to prevent them. That's why we need the userspace out-of-memory killer to kick in before the kernel.

It just started using swap space.

Yes, that's expected. Swap space also needs to be filled completely (or disabled for testing) to get into a real out-of-memory situation where oom killers kick in.

Fwiw, when trying to fill more than few GBs of RAM using the reproducer, sometimes the RAM just stops filling up at some point. In that case, just open more GNOME Terminal tabs and run the reproducer there in parallel.

I set swappiness to 0 and tried again. Lots of browser windows lots of websites several applications. The swap stayed at 0 but the memory usage never exceeded ~65% no matter what I did. There were no OOMs or other misbehavior.

I just tried again same method as above, but I also ran the reproducer. after about a minute I got the OOM message on the terminal page. Just the reproducer was killed. The terminal was still working. One interesting thing System Monitor still showed swap at 0, but the swappiness was back to 60 which I believe is the default. I had not rebooted the system.

This is a longstanding issue and it's not going to be solved on F40 timeframe. Blocking on an issue that won't be fixed doesn't make sense.

FinalBlocker -1

AGREED RejectedFinalBlocker

Discussed during the 2024-03-04 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as we can't find a justification for calling this a release blocker. Even if systemd-oomd never kicks in at all, we have no release criteria covering what should happen if you run your system out of memory, and it will always be something bad. There's no requirement in Fedora that the bad thing be "systemd kills an app" rather than "the kernel kills an app" or "everything seizes up".

[0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-03-04/f40-blocker-review.2024-03-04-17.00.log.txt

The following votes have been closed:

• Rejected FinalBlocker (+0, 0, -2)
  • -1 by nielsenb, catanzaro

Release F40 is no longer tracked by BlockerBugs, closing this ticket.