SYSTEMD-OOMD.SERVICE(8)

💖 SYSTEMD-OOMD.SERVICE(8) 💖 aka the manual page for systemd-oomd.service and systemd-oomd 🫶

---

🌸 NAME 🌸

systemd-oomd.service, systemd-oomd — a userspace out-of-memory (OOM) killer 💀✨

---

🎀 SYNOPSIS 🎀

systemd-oomd.service

/usr/lib/systemd/systemd-oomd

---

🦋 DESCRIPTION 🦋

okay so bestie, listen 👑 — systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take corrective action before an OOM occurs in the kernel space. it's giving preventative main character energy fr fr 💅

you can enable monitoring and actions on units by setting ManagedOOMSwap= and ManagedOOMMemoryPressure= in the unit configuration, see systemd.resource-control(5). systemd-oomd retrieves information about such units from systemd(1) when it starts and watches for subsequent changes. the way it just... keeps watching 👀

cgroups of units with ManagedOOMSwap= or ManagedOOMMemoryPressure= set to kill will be monitored. systemd-oomd periodically polls PSI statistics for the system and those cgroups to decide when to take action. if the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. yeah. all of them. not me being dramatic, that's literally what it does 😭🔥

⚠️ okay this part matters, don't skip it: note that only descendant cgroups are eligible candidates for killing — the unit with its property set to kill is not a candidate (unless one of its ancestors set their property to kill). Also only leaf cgroups and cgroups with memory.oom.group set to 1 are eligible candidates; see OOMPolicy= in systemd.service(5). that's the vibe check for eligibility, periodt 💅

oomctl(1) can be used to list monitored cgroups and pressure information. cute little inspector 🎀

see oomd.conf(5) for more information about the configuration of this service.

see org.freedesktop.oom1(5) and org.freedesktop.LogControl1(5) for a description of the D-Bus API. ✨

---

🌈 SYSTEM REQUIREMENTS AND CONFIGURATION 🌈

the system must be running systemd with a full unified cgroup hierarchy for the expected cgroups-v2 features. no half-measures, bestie 🫶 Furthermore, memory accounting must be turned on for all units monitored by systemd-oomd. the easiest way to turn on memory accounting is by ensuring the value for DefaultMemoryAccounting= is set to true in systemd-system.conf(5). slay, that's it, that's the whole trick 💅

the kernel must be compiled with PSI support. this is available in Linux 4.20 and above. so like... if you're on something ancient, that's a you problem 🙈

it is highly recommended for the system to have swap enabled for systemd-oomd to function optimally. with swap enabled, the system spends enough time swapping pages to let systemd-oomd react. without swap, the system enters a livelocked state much more quickly and may prevent systemd-oomd from responding in a reasonable amount of time 😭 See "In defence of swap: common misconceptions"[1] for more details on swap.

any swap-based actions on systems without swap will be ignored. while systemd-oomd can perform pressure-based actions on such a system, the pressure increases will be more abrupt and may require more tuning to get the desired thresholds and behavior. tune responsibly, okay? 🔥

💀 be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). literally everything. gone. 🙈 if you're using a desktop environment like GNOME or KDE, it already spawns many session components with the systemd user manager — so you're lowkey covered 💜

---

⭐ USAGE RECOMMENDATIONS ⭐

ManagedOOMSwap= works with the system-wide swap values, so setting it on the root slice -.slice, and allowing all descendant cgroups to be eligible candidates may make the most sense. like, go broad or go home 🎀

ManagedOOMMemoryPressure= tends to work better on the cgroups below the root slice. for units which tend to have processes that are less latency sensitive (e.g. system.slice), a higher limit like the default of 60% may be acceptable, as those processes can usually ride out slowdowns caused by lack of memory without serious consequences. however, something like user@$UID.service may prefer a much lower value like 40%. iykyk 💅

---

✨ OPTIONS ✨

• --dry-run — do a dry run of systemd-oomd: when a kill is triggered, print it to the log instead of killing the cgroup 👀 it's giving "look but don't touch" energy and honestly? iconic.

Added in version 253.

• -h, --help — print a short help text and exit. the classic 🫶
• --version — print a short version string and exit. also the classic 💖

---

🧚 SIGNALS 🧚

• SIGHUP — upon reception of the SIGHUP process signal systemd-oomd will reload its configuration file. refresh queen 🔄✨

Added in version 258.

---

🌸 SEE ALSO 🌸

systemd(1), systemd-system.conf(5), systemd.resource-control(5), oomd.conf(5), oomctl(1), org.freedesktop.oom1(5)

---

💜 NOTES 💜

1. "In defence of swap: common misconceptions" — https://chrisdown.name/2018/01/02/in-defence-of-swap.html

---

okay that's the whole page bestie, go forth and not get OOM-killed 💅 🦋🌸🍓

this lil rewrite was brought to you by systemd 261.3 — it's on the SYSTEMD-OOMD.SERVICE(8) page, mwah 💋