Systemd-oomd.service fails at bootup

Not sure how to troubleshoot this service failure. It popped up after updating to manjaro-system-20220115-1.

Any ideas on how to configure this service for success will be much appreciated.

systemctl status 'dbus-org.freedesktop.oom1.service'
○ systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; enabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: × systemd-oomd.socket
  Condition: start condition failed at Mon 2022-01-24 18:53:45 EST; 2h 4min ago
             └─ ConditionPathExists=/proc/pressure/memory was not met
       Docs: man:systemd-oomd.service(8)```

Same here, no solution found yet.

Found it… but we need a kernel config change: CONFIG_PSI=y

@Darksky and @Strit could we get this added? Maybe disable systemd-oomd by default, not sure how it behaves on low memory boards.

I read about PSI (pressure stall information) in one of the manpages but didn’t know how to check to see if it was enabled. For now, I have disabled the service.

According to the link that @0n0w1c provides there should have a /proc/pressure directory with 3 files in it: cpu, memory and Io.

systemctl status 'dbus-org.freedesktop.oom1.service'                                                                                     ✔ 
○ systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ○ systemd-oomd.socket
       Docs: man:systemd-oomd.service(8)

I’ll enable it for my kernels during next kernel builds.

Thanks for the find!

@Darksky I am not sure if you plan to add CONFIG_PSI=y, but if you do… maybe add CONFIG_PSI_DEFAULT_DISABLED=y, then add psi=1 to cmdline.txt. This will allow folks to disable it by removing that parameter, per this post.

Why not just disable the systemd-oomd service if they don’t want it?

Having a way to disable it at boot time might be helpful… maybe it does not work well on an rpi3 with only 1GB. I was not aware of the disable option, and since I brought up adding the option, figured I should share what I find that might be relevant.

I have PSI enabled in the latest linux-rpi4-mainline kernel in unstable and was testing it today systemd-oomd and I get this and so far I have not found how or where to set ConditionControlGroupController=memory.

The service does not seem to be recommended by RPi because of resources used and I do not know if I will ever use it here. I have been using the Pi’s for many years with no problem without it. I wonder if is the case of some overthinking.

[ray@pi4 ~]$ systemctl status systemd-oomd
○ systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; enabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● systemd-oomd.socket
  Condition: start condition failed at Wed 2022-01-26 10:16:12 CST; 11min ago
             └─ ConditionControlGroupController=memory was not met
       Docs: man:systemd-oomd.service(8)

Try systemd.unified_cgroup_hierarchy=false in cmdline.txt.

Edit: Or maybe change the service file:

- ConditionControlGroupController=v2
+ ConditionControlGroupController=v1

None of those worked.

Hmm, well… I guess it may not work on a pi.

Although nothing in that link from the rpi folks saying it will not work.

Nothing in that thread about using systemd-oomd.service either; just PSI.

I’m getting that (oom) killer socket error too.
Running an RPI4 KDE plasma build that was fine till it updated yesterday - now slowed to crap and totally unusable.

What can I do to stop this, bar reinstalling with something else?

I do not know of anyone to get systemd-oomd.service to work on the RPi as of yet. When this thread was started it was deemed necessary for PSI to be in the kernel to have systemd-oomd.service work and I have done that on the later kernels but it is not enabled by default and to have it enabled you have to add psi=1 at the end of cmdline.txt and also enable systemd-oomd. No one in this thread has gotten the systemd-oomd.service to work though with the RPi.

The systemd-oomd.service not working has not been having any adverse effects with the DE’s operating. Has there been any other updates with something else like KDE or with something you installed? If Compositing is enabled disable it.

There had been a small update recently but had not paid much attention; it was kactivitymanagerd that got updated, a single package 822.8 kB.

When I rebooted and things went sticky, I ran this:

[fat@RPI4 ~]$ sudo systemctl --failed
[sudo] password for fat:
UNIT LOAD ACTIVE SUB DESCRIPTION
● systemd-oomd.socket loaded failed failed Userspace Out-Of-Memory (OOM) Killer Socket

Which I guess says it had loaded the service but it had failed; I thought that was the cause of the problem.

System monitor showed all 4 CPUs bouncing from 10% to 100% repeatedly and memory usage, normally below 700 MB with nothing running, was flat at 1.2 GB. Chromium refused to run and everything else was extremely slow. I rebooted several times, removed the SSD and wrote a new KDE image to another SSD (same type) I have spare, using another machine, got that installed and went back to the old drive on the RPI4 to try it one more time before taking files off it and found that, once booted, the problem had gone away. System monitor output looks normal again and Chromium is working. So haven’t a clue what it was, unless you can suggest something to check?

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.