Skip to content

Per-run cgroups on by default on the Hetzner stack - #410

Open
winding-lines wants to merge 2 commits into
mainfrom
cgroups-default
Open

winding-lines wants to merge 2 commits into
mainfrom
cgroups-default

Conversation

@winding-lines

Copy link
Copy Markdown
Contributor

Closes #239

What changes

  • Default on. morca-stack apply starts the scheduler with the cgroup flags (--cgroupns=private, SYS_ADMIN for the remount, dropped before morca starts, apparmor=unconfined) unless stack.conf says CGROUPS=0. CGROUPS now takes only 0 or 1.
  • Hosts that can't. Without cgroup v2 at /sys/fs/cgroup (no cgroup.controllers), or without its memory controller, the scheduler starts without the flags, as with CGROUPS=0, and apply/plan print morca-stack: run cgroups off: ....
  • Remount fallback. The entrypoint is mount -o remount,rw /sys/fs/cgroup || echo ...; exec setpriv ... morca scheduler, so a failed remount no longer leaves a crash-looping scheduler: morca sees a read-only /sys/fs/cgroup and logs run cgroups off.
  • Pre-flight. With cgroups on, apply (and plan, on stderr so deploy.sh's plan parsing is untouched) warns for each pipeline whose p95 peak over its last 20 successful local runs (at least 3, as morca.recommend) is above its memory_gb maximum, else the host's memory less MORCA_RESERVE_MEMORY_MB. Warn only; it doesn't block. The SQL was checked against a real Postgres.
  • Docs. docs/hetzner.md's "A cgroup per run" rewritten: default on, what a host that can't gets, the pre-flight, turning it off for the stack, and (no per-pipeline switch exists) how to give one pipeline room instead. DESIGN.md and hetzner.env.example updated.
  • Tests. tests/hetzner.sh: on by default, CGROUPS=0/1, CGROUPS=2 refused, the v1 host and no-memory-controller hosts, the remount fallback, and the pre-flight warnings (fake host cgroup root and meminfo via MORCA_HOST_CGROUP/MORCA_MEMINFO).

Upgrade note

A stack that never set CGROUPS gets its scheduler replaced on the next deploy (options: its flags, mounts or CGROUPS changed), which quiesces as any scheduler replacement does; stacks already on CGROUPS=1 also get one replacement for the new entrypoint. Before deploying, read the pre-flight warnings (morca-stack plan) and raise memory_gb maximums that are too low, or morca-stack configure CGROUPS=0 to keep the old behaviour.

Not in this PR: the runner split (#232) and CPU priority (#229), which the issue lists as related.

🤖 Generated with Claude Code

https://claude.ai/code/session_017TycszSbyw92Efu4ZeCYL6

winding-lines and others added 2 commits November 12, 2026 16:34
morca-stack apply now starts the scheduler with the cgroup flags unless
stack.conf says CGROUPS=0. A host without cgroup v2 or its memory
controller gets the scheduler without them, and apply and plan say why; a
failed remount no longer stops the scheduler (morca then turns run cgroups
off itself). With cgroups on, apply (and plan, on stderr) warns for each
pipeline whose p95 peak over its last 20 local runs is above its
memory_gb's maximum, or what the host can grant. CGROUPS takes 0 or 1 only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TycszSbyw92Efu4ZeCYL6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TycszSbyw92Efu4ZeCYL6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Per-run cgroups on by default

1 participant