| Ticket Hash: | c3ab7d571d58b57b266dcf3d38e3157a39d5529b | ||
| Title: | W6.1: Per-session bwrap resource bounds — disk quota, CPU, and memory limits | ||
| Status: | Active | Type: | |
| Severity: | Priority: | Low | |
| Subsystem: | Resolution: | ||
| Last Modified: |
2026-09-20 14:43:46 51.7 days ago |
Created: |
2026-09-09 14:59:56 62.7 days ago |
| Version Found In: | |||
| Description: | ||||
|
BACKLOG / roadmap item (ocx). Sessions are confined by NAMESPACE (bwrap: fs view, isolation) but have NO bounds on disk, CPU, or memory. A single session's reproduce scratch reached ~113G (reproduce-g9 58G + reproduce-bc 39G + seed-rootfs 14.6G) and a full B->C reproduce runs multi-hour on all cores — either can starve the host / other sessions. We already GC'd once by hand (2026-09-09); that surfaced the need for BOTH bounds AND GC.
Scope to design: 1. DISK — per-session storage quota or a monitored cap. Options: fs project-quota, cgroup v2 io limits + a size watchdog, or a daemon-enforced cap with the owning session doing GC in-turn (see the GC-ownership rule: workspace GC is the owning session's job; completed/closed sessions GC via session-close + cleanup_checkouts). Decide the enforcement layer + a sane default budget (steady-state ~15G + reproduce scratch ~110G => a heavy session may legitimately want ~130-150G; bounds must accommodate declared heavy work, not just clamp). 2. CPU — per-session cpu limit (cgroup v2 cpu.max / weight) so one heavy build doesn't monopolize all cores; allow a session to request a higher budget for declared heavy work (reproduce). 3. MEMORY — cgroup v2 memory.max per session to prevent OOM cascades. Mechanism note: bwrap already establishes the namespace; cgroups v2 (cpu.max / memory.max / io.max) applied to the session's process tree is the natural companion for cpu/mem/io. Disk is the harder one (quota vs watchdog+GC). Related: runaway-log incident (unbounded log = another storage-bound gap), the GC-on-completed-sessions capability (session-close + cleanup_checkouts sweep). This should live in the OCX development plan (link under the appropriate milestone during plan curation). Backlog priority — not blocking current milestones; raised by maintainer 2026-09-09. Filed so it is persisted in ocx's plan, not lost in chat. | ||||
| User Comments: | ||||
added on 2026-09-09 15:07:53:
Work item 6.1 under M6 (session resource safety). Sessions are namespace-confined but not resource-bounded. A session reached ~113 GB on disk; reproduce runs consumed multi-hour all-core CPU. This work adds bwrap cgroup/resource limits so each session sandbox is bounded: disk quota (via bwrap bind + quota or a per-namespace disk limit), CPU weight/period, and memory ceiling. Limits are configurable per-session type (coordinator vs. build vs. standard). A session that hits its limit is stopped cleanly. Design notes: bwrap supports cgroup v2 delegation; the session spec (SandboxSpec / Isolation.runner_spec) is the right place to attach limits, consistent with how network and filesystem binds are already expressed there. Default limits should be conservative (e.g. 20 GB disk, 2 CPU-hours/turn, 8 GB memory) with an override path for designated build sessions. Relates to W6.2 (periodic sweep): bounds prevent runaway growth; sweep reclaims completed leftovers. Priority: LOW. OCX-PLAN: role=work parent=ac304f977b0f99de8628d9c7cc0c1939014f9ace seq=1 | ||||