LXC Container low-memory-monitor.service failed to start

[ihr]

Hi,

I'm in the process to fine tune systemd services on my lxc containers.

I already fixed issues with sys-kernel-config.mount and systemd-journald-audit.socket following instructions here

But there is one LXC container with a service called low-memory-monitor.service that it is not starting I I don't know how to handle.

1. Journalctl says:

Feb 14 08:52:27 regulators-tomcat systemd[80]: low-memory-monitor.service: Failed to set up CPU scheduling: Operation not permitted
Feb 14 08:52:27 regulators-tomcat systemd[80]: low-memory-monitor.service: Failed at step SETSCHEDULER spawning /usr/libexec/low-memory-monitor: Operation not permitted
Feb 14 08:52:27 regulators-tomcat systemd[1]: low-memory-monitor.service: Main process exited, code=exited, status=214/SETSCHEDULER
Feb 14 08:52:27 regulators-tomcat systemd[1]: low-memory-monitor.service: Failed with result 'exit-code'.
Feb 14 08:52:27 regulators-tomcat systemd[1]: low-memory-monitor.service: Scheduled restart job, restart counter is at 1.
Feb 14 08:52:27 regulators-tomcat systemd[1]: Stopped Low Memory Monitor.
Feb 14 08:52:27 regulators-tomcat systemd[1]: Started Low Memory Monitor.

2. Other contained doesn't seem to have this service installed (not even started)

LCX OS Type is 'centos'
Container is unprivileged

And the service is available in the distribution

# dnf whatprovides "*/low-memory-monitor.service"
Last metadata expiration check: 2:13:04 ago on Wed 14 Feb 2024 07:04:44 AM UTC.
low-memory-monitor-2.1-4.el9.x86_64 : Monitors low-memory conditions
Repo        : @System
Matched from:
Filename    : /usr/lib/systemd/system/low-memory-monitor.service

low-memory-monitor-2.1-4.el9.x86_64 : Monitors low-memory conditions
Repo        : appstream
Matched from:
Filename    : /usr/lib/systemd/system/low-memory-monitor.service

It looks like this is a dependency of another installed service such as tomcat but I'm not 100% sure about that.

Options?

1. remove the service? The service is responsible of sending oom kill messages to the kernel. Obviously, in that container this is not happening so this is an option.
2. Are there more options?

Regards
Ignacio