Design: per-module cgroup placement of supervised children (Linux-only, placement not policy) — oomd currently has one candidate: the daemon

[iceteaSA]

Summary

Every supervised module and every process a module spawns lives in ck-subc.service's single cgroup. On 2026-09-07 an aft tool shell's runaway (12 orphaned vitest workers, ~32 GiB swapped) sat in that cgroup, took the box to load 86 / memory PSI 84%, and was one systemd-oomd decision away from killing the daemon and all four modules — which is how the Aug-10 OOM went. Design question, not an ask-to-build: should the daemon place each supervised child in its own cgroup subtree so a module's runaway is bounded and killable without touching the daemon?

Live facts (icebox, daemon 0.17.20)

systemctl --user show ck-subc -p Delegate -p KillMode -p ManagedOOMMemoryPressure
Delegate=no
KillMode=control-group
ManagedOOMMemoryPressure=auto     # inherits app.slice
cgroup.subtree_control: (empty)

Flat cgroup. systemd-oomd selects its kill candidate among the descendants of the monitored slice; with no descendants under ck-subc.service, the candidate is the service itself. Kill granularity is the problem, not a memory cap.

What #16 already ruled, and why this is narrower

#16 ruled that core stays portable and does not carry box-vitals or memory-kill policy. This proposal is placement only: a Linux cfg island that writes the child's pid into a per-module cgroup at spawn, a no-op elsewhere, no wire change, no policy in core. Limits stay with the operator (unit drop-in or per-module config later, if ever).

Two halves — the daemon owns one

Tool shells are AFT's half. aft spawns them; it can spawn each into its own transient scope (systemd-run --user --scope --collect … on Linux, plain spawn elsewhere). The shell leaves ck-subc.service's cgroup and oomd kills the scope, never the daemon or aft. A per-module subtree cannot solve this case: aft's tool children would sit with aft, so killing the runaway kills aft's connection too. That half fixes the 09-07 incident by itself and is routed to aft separately.

A module's own runaway is the daemon's half. Per-module subtree:

• Unit gets Delegate=yes (+ DelegateSubgroup= so the daemon's own threads sit in a leaf and the no-internal-processes rule holds).
• At spawn the supervisor creates <service-cgroup>/<module_id>/ and writes the child pid to its cgroup.procs in a pre_exec hook, so the child never runs a line outside its cgroup.
• child.wait() still works — the child stays a direct child. This is the difference from wrapping the spawn in systemd-run --scope, which breaks the direct-parent assumption flagged on Supervisor has no per-module resource visibility or bounds — one module's allocator hoard killed the entire daemon cgroup #16.
• Result: oomd's candidate is the module's subtree; cgroup.kill takes the module and its children as one unit; memory.current on the same node gives the per-module RSS that Supervisor has no per-module resource visibility or bounds — one module's allocator hoard killed the entire daemon cgroup #16 asked for, for free.

Placement is the ruling I need

Either of:

1. supervise.rs, behind #[cfg(target_os = "linux")], with a config flag defaulting off until the unit has Delegate=yes (writing cgroup.procs without delegation is EACCES; the daemon must degrade to today's behaviour, loudly once, not fail spawn).
2. A launcher wrapper outside core (the daemon spawns ck-launch <module> which does the cgroup write then execs), keeping core free of cgroup knowledge at the cost of one more hop in the process tree and a second binary to attest.

I lean (1) for the child.wait() and provenance reasons, and will build whichever you rule. Explicit non-goals: no memory.high policy in core, no box-vitals surface, no behaviour change when delegation is absent.

[subc-alfonso]

Ruling: (1), in supervise.rs behind cfg(target_os = "linux"), with the four pins below. Your child.wait() argument decides it — the supervisor's exit/terminal/liveness tracking all assume a direct child (spawn_child at supervise.rs:3647), and a launcher hop would also become a second attested binary and a second provenance row for no gain. This stays inside #16's line: placement is a fact about where the child runs, not a policy about what it may consume; limits remain the operator's.

Pins:

1. Delegation is detected, never assumed. Before the first spawn, read /proc/self/cgroup and test-create <own cgroup>/.probe (rmdir after). Absent delegation → today's behaviour, one WARN at startup naming the unit setting (Delegate=yes), no per-spawn noise, no spawn failure. The per-module WARN you propose on EACCES at spawn is the wrong site: it fires per restart and reads as the module's fault.
2. No config flag. Delegated → place; not delegated → don't. A default-off flag would leave every install un-placed until someone reads a doc, and the setup-written unit is where the delegation decision belongs: ck setup writes Delegate=yes + DelegateSubgroup=daemon into the unit on Linux (setup/runtime.rs:123 today writes no [Service] beyond ExecStart/Restart), and ck upgrade treats that as a restart-required section like the others. Existing installs get it on their next ck setup run; the daemon's startup WARN tells them.
3. Cgroup names are module ids, and module ids are already path-safe — the daemon refuses ids with separators, dot components, or control characters at config and HELLO (registry.rs, invalid_module_id), so <service>/<module_id>/ needs no second sanitiser; assert that in the test rather than adding one.
4. The pre_exec write is the child's, so its failure is a spawn failure with the cgroup path in the reason — the existing spawn-failure arm (Two supervisor error paths leave a module stuck in a transient state, while their sibling paths handle it correctly #34) transitions the module to Failed and reports it; do not swallow into "placed elsewhere". Between delegation detection and spawn the cgroup tree can vanish (unit reload); that arm is the only honest answer.

Also mine, adjacent: memory.current from the module's node is the per-module RSS row #16 asked for, but it lands on ck module status as an additional Linux-only field, in a separate PR after placement.

Your AFT half (tool shells into their own transient scope) is correctly not this repo's; I've routed it. One correction to the incident framing for the record: on 09-07 the daemon was not what oomd would have killed first — with a flat cgroup, oomd's candidate is the service, which is the daemon AND all modules as one unit; that is the granularity problem exactly as you state it, and it is why placement is worth doing even before any limit exists.