earlyoom 1.9.0 with systemd 252 (Rocky Linux 9.6)

I've noticed EPEL 9 release of earlyoom has not worked as expected on my Rocky Linux 9.6 with the latest Mate Desktop, 1.28 / 1.29 custom built (I've been getting system lockups / freezes...). I've therfore rebuilt the latest Fedora 44 release - version 1.9.0. Immediately after installation, at service start, I got: `systemd[1]: /usr/lib/systemd/system/earlyoom.service:47: Failed to parse system call, ignoring: process_mrelease` Googling about, I've found a very nice article about, at: https://blog.gitcode.com/6e6af194c10a8a30005e57188be4fdf7.html **Here is google translated content:** When running earlyoom version 1.8.2 on a Rocky Linux 9 system, users reported a compatibility issue related to systemd. When earlyoom attempts to terminate a service process, systemd unexpectedly terminates earlyoom itself, causing the service to restart. This article will analyze the cause and solution of this problem in detail. **Problem Symptoms** Users observed the following typical symptoms: When system memory falls below a set threshold, earlyoom begins terminating processes as expected. After terminating the process, systemd records that the earlyoom service was terminated by a signal. Systemd then automatically restarts the earlyoom service. The system log shows a SECOMP audit message, indicating that the system call was rejected. **Root Cause Analysis** Through detailed technical investigation, the problem was found to stem from a compatibility issue between systemd's system call filtering mechanism and new features of the Linux kernel: 1. The `process_mrelease` system call: This is a relatively new Linux kernel system call (number 448) used for efficient process memory release. earlyoom calls this system call after terminating a process to optimize memory reclamation. 2. Systemd Version Limitation: Rocky Linux 9 uses systemd version 252, which cannot correctly recognize the `process_mrelease` system call, causing errors when parsing service configuration files. 3. Security Mechanism Conflict: systemd's `SystemCallFilter` mechanism incorrectly identifies `process_mrelease` as an unauthorized system call, triggering the SIGSYS signal and terminating the earlyoom process. **Solutions** There are several solutions to this problem: 1. Completely remove the `SystemCallFilter` line: Edit the `/usr/lib/systemd/system/earlyoom.service` file and delete the line containing `SystemCallFilter`. This is the simplest solution, but it will reduce some security. 2. Remove only `process_mrelease`: Retain the basic functionality of `SystemCallFilter`, removing only unrecognized system calls: `SystemCallFilter=@system-service` 3. System upgrade solution: Upgrade to a newer version of systemd that supports `process_mrelease` Ensure the kernel version is recent enough (5.14 or higher) **Technical background supplement:** The `process_mrelease` system call is a new feature introduced in Linux kernel version 5.14, specifically designed for efficiently reclaiming the memory of terminated processes. Compared to traditional memory reclamation mechanisms, it releases memory more promptly, making it particularly suitable for memory management tools like earlyoom. systemd's `SystemCallFilter` mechanism is a security feature used to restrict the system calls that services can execute. Older versions of systemd may experience compatibility issues when the configuration includes unrecognized system calls. **Best practice recommendations:** Before deploying earlyoom, verify the system environment: Check if the systemd version supports the required system calls Confirm the kernel version is recent enough I think something like that should be included somewhere in earlyoom documentation, and I am posting it here to help other users with such an issue (I've also found a closed issue #328 about that, but advice published there is not the best one, by my opinion). Rebuilt earlyoom with modified service file (with just `SystemCallFilter=@system-service`, without `process_mrelease` part) finally brought me to a working solution, as much as I've tested by now. My system finally doesn't freeze anymore, and earlyoom seem to work as expected now - here is a part of `tail /dev/zero` test: ``` mem avail: 395 of 12403 MiB ( 3.19%), swap free: 54 of 12287 MiB ( 0.44%) mem avail: 232 of 12648 MiB ( 1.84%), swap free: 0 of 12287 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.60%, swap 10.00% sending SIGTERM to process 269087 uid 1000 "Web Content": oom_score 1122, oom_score_adj 233, VmRSS 12 MiB, cmdline "/usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:52571 -prefMapHandle 1:457158 -jsInitHandle 2:242716 -parentBuildID 20251016011024 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {535429e1-4ea8-4cf6-a489-8467c9f1250" kill_release: pid=269087: process_mrelease pidfd=4 success process 269087 exited after 0.100 seconds mem avail: 138 of 12671 MiB ( 1.10%), swap free: 0 of 12287 MiB ( 0.00%) low memory! at or below SIGKILL limits: mem 1.30%, swap 5.00% sending SIGKILL to process 4806 uid 1000 "Isolated Web Co": oom_score 1086, oom_score_adj 167, VmRSS 89 MiB, cmdline "/usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:51160 -prefMapHandle 1:457158 -jsInitHandle 2:242716 -parentBuildID 20251016011024 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {5293e643-0fb1-43b5-b0fb-700f443c58a" kill_release: pid=4806: process_mrelease pidfd=4 success process 4806 exited after 0.100 seconds mem avail: 197 of 12670 MiB ( 1.56%), swap free: 0 of 12287 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.60%, swap 10.00% sending SIGTERM to process 269688 uid 1000 "tail": oom_score 1088, oom_score_adj 0, VmRSS 10855 MiB, cmdline "tail /dev/zero" kill_release: pid=269688: process_mrelease pidfd=4 success process 269688 exited after 0.100 seconds mem avail: 10951 of 12654 MiB (86.54%), swap free: 6686 of 12287 MiB (54.42%) ```