Files
Arnaud GourlayandClaude Opus 5 5b338115f2 Replace cgroups-rs with direct cgroup memory file reads (#10295)
* Replace cgroups-rs with direct cgroup memory file reads

We used cgroups-rs in exactly one place, to read the memory limit and
usage of our own cgroup, so read those files directly instead. Drops 34
crates from the lockfile, including the zbus stack that carries
RUSTSEC-2026-0221.

Also fixes two latent cgroup v1 bugs (the LONG_MAX unlimited sentinel
reported ~9 EB of total memory, an unreadable limit file reported 0
bytes) and the hierarchy mix-up on hybrid hosts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Decline cgroup memory reporting when the usage read fails

Reporting a usage of 0 made available_memory_bytes claim the whole cgroup
limit as free. Fall back to sysinfo when the usage file cannot be read at
init, and keep the last known value on a failed refresh.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Keep the last known memory limit when its read fails

A transient read failure cleared the cached limit and silently fell back
to host memory while the process was still capped, the same direction of
over-reporting as the usage read. Both now keep their last known value,
and a limit lifted at runtime still clears.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Treat a malformed memory limit as an error, not as unlimited

Parse failures returned Ok(None), so garbage in the limit file cleared a
valid cached limit on refresh and read as unlimited at init. Reserve
Ok(None) for "max" and the v1 sentinel, and report anything else as
InvalidData so the last known limit survives.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-24 15:08:00 +02:00
..
2024-11-27 11:24:58 +01:00
2025-09-29 12:47:10 +00:00
2024-11-27 11:24:58 +01:00