Apparently the user slice and root slice weren't being configured correctly and oomd was not stepping in during high swap pressure events before the kernel oom killer showed up to the party. This (hopefully) properly configures systemd-oomd now... The configuration was inspired by Fedora. https://fedoraproject.org/wiki/Changes/EnableSystemdOomd I used the test in that wiki page to confirm it's now properly configured: $ systemd-run --user tail /dev/zero $ journalctl -f ... systemd[1081]: Started [systemd-run] /usr/bin/tail /dev/zero. systemd-oomd[517]: Considered 79 cgroups for killing, top candidates were: systemd-oomd[517]: Path: /user.slice/user-10000.slice/user@10000.service/app.slice/run-p5146-i5147.service systemd-oomd[517]: Swap Usage: 4.6G systemd-oomd[517]: Killed /user.slice/user-10000.slice/user@10000.service/app.slice/run-p5146-i5147.service due to memory used (2458> systemd[1081]: run-p5146-i5147.service: systemd-oomd killed 1 process(es) in this unit. systemd[1081]: run-p5146-i5147.service: Main process exited, code=killed, status=9/KILL systemd[1081]: run-p5146-i5147.service: Failed with result 'oom-kill'. Signed-off-by: Clayton Craft <craftyguy@postmarketos.org> Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7556>
4 lines
74 B
Plaintext
4 lines
74 B
Plaintext
[Service]
|
|
ManagedOOMMemoryPressure=kill
|
|
ManagedOOMMemoryPressureLimit=80%
|