Cap CPU, memory and task count of a systemd service with cgroup v2 resource controls

Documented steps

1. Confirm unified cgroup hierarchy (cgroup v2): `stat -fc %T /sys/fs/cgroup` should print `cgroup2fs`. CPUWeight/MemoryMax/MemoryHigh/TasksMax/IOWeight require it.
2. In the unit's [Service] section: CPUQuota=150% MemoryHigh=1G MemoryMax=1536M TasksMax=256 CPUWeight=100 CPUQuota=150% means at most 1.5 CPUs worth of time. MemoryHigh throttles/reclaims above 1G; MemoryMax=1536M is the hard cap where the kernel OOM-kills the cgroup.
3. Prefer MemoryHigh as the main control and keep MemoryMax as a backstop above it — MemoryHigh degrades gracefully, MemoryMax kills.
4. Values accept K/M/G/T suffixes, percentages of physical RAM (MemoryMax=10%), or `infinity`.
5. Apply at runtime without a restart: `systemctl set-property myapp.service MemoryMax=1536M CPUQuota=150%` — this also persists by writing a drop-in under /etc/systemd/system/myapp.service.d/. Add `--runtime` to make it non-persistent (drop-in under /run).
6. Verify live usage: `systemd-cgtop` for per-unit CPU/mem/IO, and `systemctl status myapp` shows Memory: current (high/max echoed since systemd 252ish) and Tasks: counts. `systemctl show myapp -p MemoryCurrent,EffectiveMemoryMax,TasksCurrent` gives machine-readable values.
7. A cgroup OOM kill appears in the journal as `myapp.service: A process of this unit has been killed by the OOM killer.` and, with Restart=on-failure/always configured, the service is restarted; oom-kill also appears as the unit Result.