fix(#496): verify cgroup delegation is active + state the real consequence

[shujaatTracebloc]

#496 — verify cgroup delegation is active (don't assume)

_write_cgroup_delegation wrote user@.service.d/delegate.conf + ran systemctl daemon-reload, then unconditionally printed "Delegated cpu/cpuset/io … A re-login may be needed." But daemon-reload re-reads unit files without restarting the running user@$(id -u).service, so cpu/cpuset/io aren't in effect for that session — and the k3d node inherits the delegation state from when it's created. So limit-bearing pods run unconstrained until a re-login and a cluster recreate, while the install looks green. The old wording ("may be needed") understated it.

Fix — the issue's recommended Option 3 (verify, don't assume)

Not Option 2 (systemctl restart user@…) — that kills the user's session processes; the issue says instruct, not perform.

• New _cgroup_controllers_active reads the live cgroup.controllers of the user slice (/sys/fs/cgroup/user.slice/user-$(id -u).slice/cgroup.controllers; overridable for tests) and is true only when cpu+cpuset+io are all delegated (memory/pids are default).
• After the reload, _write_cgroup_delegation checks it:
  • active → success "… active in this session."
  • not active → a loud warn: limits won't enforce until a re-login andk3d cluster delete <name> + re-run — "the install looks healthy, but limit-bearing workloads run unconstrained."

Acceptance

• The gap is now observable (read the controllers) rather than inferred, and the message states the real consequence (re-login and recreate), not just "may be needed".

Context (from the issue)

Lower severity in practice: behind the opt-in TB_TIER1_ROOTLESS flag (not the validated default, no customer install takes it today), and the path was always non-fatal. This makes the under-stated case honest and verifiable.

Tests

_cgroup_controllers_active (all-present / missing-one / unreadable), and _write_cgroup_delegation's active-vs-not report. shellcheck --severity=error + check-style + check-drift clean; full setup-linux.bats green (126); scripts/manifest.sha256 regenerated (R8).

Closes#496

---

Note

Medium Risk
Changes rootless Tier 1 install/prepare-host behavior and messaging around cgroup delegation; incorrect checks could mislead users about limit enforcement, but scope is installer scripts and tests only.

Overview
The Linux installer no longer treats writing the user@.service cgroup delegation drop-in as success. It reads livecgroup.controllers under user@$UID.service (not the enclosing slice, which can falsely look delegated) and only reports delegation as active when cpu, cpuset, and io are present.

_write_cgroup_delegation and _ensure_cgroup_delegation always run _report_cgroup_delegation on every path, including when the drop-in already exists, so re-runs don't silently skip a written-but-not-yet-live delegation. Idempotent content checks use unprivileged cmp instead of sudo cmp.

Full installs get a clear warning that pod CPU/memory limits won't enforce until the user manager restarts (re-login or reboot with lingering) and the k3d cluster is recreated. prepare-host uses TB_PREPARE_HOST_MODE so messaging targets the researcher's next login and omits cluster-delete advice.

Bats coverage and scripts/manifest.sha256 are updated for the changed setup-linux.sh.

^{Reviewed by Cursor Bugbot for commit 78c9de2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saadqbal]

Two things undercut the fix — both make the new behaviour dead on its real paths, and both are masked by tests that set state by hand. Details inline.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e5a598e. Configure here.}

[LukasWodka]

/fr-pass