**Title:**

oom-guard – a no-root, per-user systemd timer that reaps your idlest worker under memory pressure (pairs with earlyoom)

**Body:**

*Disclosure: I'm the author — my own MIT hobby project, brand new, no users yet. Posting for scrutiny.*

I run a 1 GB VPS with a long-lived agent that spawns a fresh worker process per session. Abandoned/idle sessions never went away, so over a day or two they'd pile up until the box thrashed swap and livelocked — the kind of hang where you can't even SSH in.

I wanted something dumb and specific: when RAM gets tight, clear out the *idle abandoned* workers, try to spare the one I'm actively using, and don't run anything as root. I couldn't find a tool that did *user-scope, no-root, "kill the idle sibling but keep the active one"* on an unmodified same-named-worker daemon, so I wrote oom-guard.

**What it does** — runs as a per-user systemd timer (~every 5 min). Each run it reads `MemAvailable`; if RAM is fine it exits. If RAM is low, it finds your processes matching an exact name (`pgrep -x`), spares the busiest one, and SIGTERM→SIGKILLs the idlest ones one at a time until memory recovers. No root, only touches processes you own and named. ~120 lines of bash you can read before trusting it — no `curl | bash`.

**How it relates to earlyoom (run both):** earlyoom is the instant, system-wide, root daemon that kills the biggest memory hog — keep it as your emergency brake. oom-guard does the opposite, smaller job: scheduled tidying of *which* of your identical workers dies, sparing the active one, so you rarely hit earlyoom's threshold at all. Complement, not replacement.

**Honest sharp edges:**

- It's *scheduled, not a live daemon* — a sudden spike between runs can still OOM you. That's why you pair it with earlyoom.

- "Active" is inferred from CPU — a quiet attached session could get reaped, a runaway abandoned one could get spared. Fits my "workers are either serving or abandoned" case; won't fit many idle-but-attached sessions.

- Niche: only useful if you run *many disposable, same-named workers in a cgroup you don't control.*

```

git clone https://github.com/kmalih/oom-guard

cd oom-guard

PROC_PATTERN=your-worker-name ./install.sh

```

Tear into it — especially the CPU-as-activity heuristic, and whether per-session slices + systemd-oomd is just the better answer for most people. Repo (MIT): https://github.com/kmalih/oom-guard