xai-org/grok-build · error · std::io::Error

Could not find cgroupv2 entry in /proc/self/cgroup

Error message

Could not find cgroupv2 entry in /proc/self/cgroup

What it means

read_self_cgroup parses /proc/self/cgroup looking for a cgroupv2 unified-hierarchy line with the "0::" prefix. If no such line is found (the file exists but contains only cgroup v1 hierarchy entries, or none), the function returns io::ErrorKind::NotFound. It is used by create to locate the process's cgroup path for resource control.

Source

Thrown at crates/codegen/xai-grok-tools/src/computer/local/cgroup.rs:173

                break;
            }
            guard.clear_ready();
            Ok(())
        }
    }

    // ── Cgroup helpers ───────────────────────────────────────────────────

    /// Read `/proc/self/cgroup` to find our own cgroup path (cgroup v2 unified).
    fn read_self_cgroup() -> std::io::Result<String> {
        let contents = std::fs::read_to_string("/proc/self/cgroup")?;
        // In cgroupv2 unified hierarchy, the line is "0::<path>"
        for line in contents.lines() {
            if let Some(rest) = line.strip_prefix("0::") {
                return Ok(rest.to_owned());
            }
        }
        Err(std::io::Error::new(
            std::io::ErrorKind::NotFound,
            "Could not find cgroupv2 entry in /proc/self/cgroup",
        ))
    }

    /// Parse the `high <N>` counter from `memory.events` contents.
    fn parse_memory_events_high(contents: &str) -> Option<u64> {
        for line in contents.lines() {
            if let Some(value) = line.strip_prefix("high ") {
                return value.trim().parse::<u64>().ok();
            }
        }
        None
    }

    // ── CgroupHandle ─────────────────────────────────────────────────────

    /// Owns the lifecycle of a child cgroup directory.

View on GitHub (pinned to bc7f02eddd)

Solutions

1. Migrate the host to cgroup v2 unified hierarchy (boot with systemd.unified_cgroup_hierarchy=1 or upgrade the distro).
2. Verify /proc/self/cgroup contains a "0::" line: cat /proc/self/cgroup.
3. Guard the create() call and fall back to running without cgroup-based limits when NotFound is returned.
4. Check container runtime cgroup driver configuration (switch to systemd/cgroup v2 driver).

Example fix

// before
let cgroup = Cgroup::create(...)?;
// after
let cgroup = match Cgroup::create(...) {
    Ok(c) => Some(c),
    Err(e) if e.kind() == std::io::ErrorKind::NotFound => {
        tracing::warn!("cgroupv2 unavailable, running without cgroup limits");
        None
    }
    Err(e) => return Err(e),
};

let has_v2 = std::fs::read_to_string("/proc/self/cgroup")
    .map(|c| c.lines().any(|l| l.starts_with("0::")))
    .unwrap_or(false);
if !has_v2 { /* skip cgroup setup or abort with clear config error */ }

match Cgroup::create(...) {
    Ok(c) => Some(c),
    Err(e) if e.kind() == std::io::ErrorKind::NotFound => {
        tracing::warn!("no cgroupv2 entry; limits disabled");
        None
    }
    Err(e) => return Err(e.into()),
}

When it happens

Trigger: Calling create() on a host running cgroup v1 (hybrid/legacy hierarchy) where /proc/self/cgroup has lines like "12:pids:/..." but no "0::<path>" line; running inside containers/namespaces where the cgroup file is masked or empty.

Common situations: Older Linux distributions (pre-systemd v2 adoption, e.g. CentOS 7) using cgroup v1; Docker/Kubernetes setups with cgroup v1 driver; WSL1 or environments without cgroupv2 unified hierarchy; /proc not mounted properly in a chroot.

Related errors

• no clipboard backend available
• NotFound
• <invalid u64 in memory.current>
• session '{name}' not found
• unix socket path too long: {}

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/b453c6c5a8931cf3. Report an issue: GitHub.