Help: systemd keeps OOM-killing my 256MB box

Systemd keeps killing my 256MB box. Pasting unit file below.

[Unit]
Description=small web servr

[Service]
ExecStart=/usr/local/bin/myapp
Restart=always

[Install]
WantedBy=multi-user.target

Oom-killed every few hours. Prices only go up but 256MB is what I can afford. /24 will cost you a kidney and so will RAM apparently.

• Check DefaultMemoryAccounting in systemd 238+. It defaults to yes since v238 and enables memory accounting for all units, including slices.
• Your 256MB VPS likely has a user.slice that systemd now tracks. The kernel OOM killer then targets your service because the slice overhead leaves insufficient headroom.
• Add DefaultMemoryAccounting=no to /etc/systemd/system.conf, or explicitly set MemoryAccounting=no in your unit.
• Alternative: set MemoryMax=200M in your unit to create a hard boundary systemd respects before kernel OOM intervenes.

Recommendation: test with MemoryAccounting=no first, monitor for 24 hours, then evaluate if MemoryMax provides better predictability.

I have seen this exact pattern. Systemd's defaults are aggressively tuned for modern hardware. On 256MB they become hostile.

Add MemoryAccounting=no. Also consider MemorySwapMax=0 if your provider has swap on NVMe and you want predictable failure modes. Otherwise the servr thrashes before dying.

The real fix is DefaultMemoryAccounting=no system-wide. But document it. Future you will wonder why cgroups aren't collecting metrics.

-- Marcus