[Bug 1980169] Re: systemd-oomd without swap kill does nothing and we are back to no user space oom killer.

[Tim Richardson]

Thanks for the fast reply.
Is a non-responsive session better than a killed browser? No. It's a
step backwards, because when CPU load hits 70 and there is no memory,
the user has to reboot or otherwise kill the session, losing not just
the browser, but everything.
Previously in my testing sometimes the whole session was lost. This is
now the guaranteed outcome when we run out of memory.

The proposed upstream solution is to stop the browser being killed,
which is what has been achieved now anyway. The problem is that if the
browser is not killed and it is using all the memory, how is it
different to the OOMSwap=auto default we now have, once less
privileged apps get killed?
What exactly is the desired solution, surely there is a better outcome
than killing the browser (or session), or having the system freeze? It
seems we are stuck in oscillation between these two states.
Apart from knowing what you are aiming at, I also wonder if there are
test cases, or if fixes are just more or less guesses to see what
happens?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1980169

Title:
  systemd-oomd without swap kill does nothing and we are back to no user
  space oom killer.

Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I have a 4GB Ram 2 core VM running a fresh install of 22.04 with proposed enabled.
  I have the latest systemd-oomd which no longer kills based on swap usage.

  In fact, it doesn't really kill at all, it seems.
  I have three times in a row made my session freeze with all the behaviour we see when there is no user space oom killer.

  To do this, I start chromium and use the trackthis.link site to load
  100 tabs (turn off pop-up blocking). For Firefox, it loads only 20
  tabs, which doesn't seem to quite use all memory. You can open a new
  tab and repeat the process to load another 20.

  Previously, systemd-oomd was killing the browser, although a few times
  I got it to kill the entire gnome session in a way I can not
  replicate, but it seems to happen when I am opening another app while
  the browsers are busy loading tabs.

  Now, it does not kill at all. I have a 2-core CPU load of > 70, 100%
  CPU, 100% swap and 99% Mem usage (in glances) and no interactive
  response. I have a Force Quit dialog for Firefox that is not
  responding, my two terminal windows  do not respond. This is really
  basically the same as the bad old days when we could wait a long time
  for the kernel killer to work, or we just give up on the session and
  reboot.

  Far be it from me to give advice, but it doesn't look to me that
  systemd-oomd is going to work with default Ubuntu swap config. This is
  now out of the frying pan and into the fire.

  I tested earlyoom too. It is completely predictable. It always kills
  the browser, it has never killed the session.

  Firefox and Chrome are supposed to discard tabs, but this process is
  much too slow to fight the rapid loading of tabs in this test case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1980169/+subscriptions