risingwavelabs/risingwave · warning · std::io::Error

failed to parse, path

Error message

failed to parse, path: {file_path}, content: {content}, error: {e}

What it means

`parse_error` is a helper that wraps any parse failure of a cgroup interface file into `io::Error(InvalidData)` with the file path, raw content, and underlying error in the message, to make cgroup-limit debugging diagnosable.

Solutions

1. Read the path from the error message and verify its content is parseable (e.g. integers or 'max').
2. Ensure the container exposes a proper cgroup v2 unified hierarchy.
3. Sanitize content (trim) and confirm no locale/exotic characters in the file.
4. Patch/fallback: treat unparseable limit as unlimited and log a warning.

Example fix

// before
let v = read_usize("/sys/fs/cgroup/cpu.max")?; // errors on "max 100000"
// after: validate content first
let content = std::fs::read_to_string("/sys/fs/cgroup/cpu.max")?;
if content.split_whitespace().next() == Some("max") { /* no limit */ } else { let v = read_usize("/sys/fs/cgroup/cpu.max")?; }

fn parseable_int(path: &str) -> bool {
    std::fs::read_to_string(path).map(|c| c.trim().parse::<usize>().is_ok()).unwrap_or(false)
}

match read_usize(path) {
    Err(e) if e.kind() == std::io::ErrorKind::InvalidData => {
        // e.to_string() includes path, content, and cause — log and fall back
        fallback();
    }
    other => other?,
}

When it happens

Trigger: Any of `get_cpu_limit_v2`, `read_usize`, `read_usize_or_max` reading a cgroup file whose content cannot be parsed into the expected integer(s).

Common situations: cgroup files containing 'max', empty content, or trailing garbage; wrong file paths containing human-readable text; nested-container layouts with unexpected values.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• not a number
• Failed to get available parallelism, error
• Invalid format in Cgroup CPU interface file, path
• <parse error of commit_checkpoint_interval
• {0}

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/936c4bfe3c149471. Report an issue: GitHub.

Appendix: source

Thrown at src/utils/resource_util/src/lib.rs:378

        match fs_err::read_to_string(file_path) {
            Ok(controller_string) => {
                for controller in controller_string.split_whitespace() {
                    if controller.eq(controller_name) {
                        return true;
                    };
                }
                false
            }
            Err(_) => false,
        }
    }

    pub fn parse_error(
        file_path: &str,
        content: &str,
        e: impl std::fmt::Display,
    ) -> std::io::Error {
        std::io::Error::new(
            std::io::ErrorKind::InvalidData,
            format!("failed to parse, path: {file_path}, content: {content}, error: {e}"),
        )
    }

    /// Reads an integer value from a file path.
    pub fn read_usize(file_path: &str) -> Result<usize, std::io::Error> {
        let content = fs_err::read_to_string(file_path)?;
        let limit_val = content
            .trim()
            .parse::<usize>()
            .map_err(|e| parse_error(file_path, &content, e))?;
        Ok(limit_val)
    }

    /// Helper function that helps to retrieve value in file, if value is "max", `max_value` will be
    /// returned instead.
    pub fn read_usize_or_max(file_path: &str, max_value: usize) -> Result<usize, std::io::Error> {

View on GitHub (pinned to 6469eb736d)