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

[Tim Richardson]

Public bug reported:

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.

** Affects: systemd (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  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. 
+ 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. 
+ 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 to do 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.
+ 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. 
+ 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.

-- 
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:
  New

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