tinyhumansai/openhuman · error

command failed with status {}

Error message

command failed with status {}

What it means

run_capture is run_checked's capturing sibling, used where the service command's stdout is parsed (status queries such as launchctl print or systemctl status): a non-zero exit bails with the status, and unlike the success path, both stdout and stderr are discarded on failure — the real reason must be found by rerunning the command manually.

Source

Thrown at src/openhuman/platform/service/common.rs:132

}

#[cfg(not(windows))]
fn no_window(_cmd: &mut Command) {}

pub(crate) fn run_checked(cmd: &mut Command) -> Result<()> {
    no_window(cmd);
    let status = cmd.status()?;
    if !status.success() {
        anyhow::bail!("command failed with status {status}");
    }
    Ok(())
}

pub(crate) fn run_capture(cmd: &mut Command) -> Result<String> {
    no_window(cmd);
    let output = cmd.output()?;
    if !output.status.success() {
        anyhow::bail!("command failed with status {}", output.status);
    }

    Ok(String::from_utf8_lossy(&output.stdout).to_string())
}

pub(crate) fn run_best_effort(cmd: &mut Command) {
    no_window(cmd);
    match cmd.stdout(Stdio::null()).stderr(Stdio::null()).status() {
        Ok(status) => {
            if !status.success() {
                log::debug!("[service] best-effort command failed with status {status}");
            }
        }
        Err(err) => {
            log::debug!("[service] best-effort command failed to execute: {err}");
        }
    }
}

View on GitHub (pinned to 7491200858)

Solutions

  1. Rerun the underlying command manually with stderr visible to get the real message.
  2. Treat status-query failure as degraded rather than fatal — the service may simply not be installed.
  3. For transition races, retry the status query once after a short delay before concluding failure.
Defensive patterns

Strategy: try-catch

Validate before calling

// Before shelling out to query status, confirm the service is installed at all
// (uninstalled ⇒ the status command exits non-zero by design)
let unit = std::env::var("HOME").ok()
    .map(|h| std::path::PathBuf::from(h).join(".config/systemd/user/openhuman-core.service"));
if unit.as_ref().map(|p| !p.exists()).unwrap_or(false) {
    // report NotInstalled instead of running the command
}

Try / catch

Wrap status queries so a non-zero exit maps to a NotInstalled/Degraded state in the UI instead of an error toast; on the retry path, capture stderr with .output() so the reason is not lost.

Prevention

When it happens

Trigger: Status-query commands failing: launchctl print on restricted macOS environments (the macOS module keeps a fallback for exactly this), systemctl status against a dead or masked unit, sc query against a service that was removed — commonly hit while polling status during install/uninstall transitions.

Common situations: Status polling after a crashed or uninstalled service; macOS contexts without a GUI session; races where status is queried mid-uninstall so the unit no longer exists.

Related errors


AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/5a71c292d256b137. Report an issue: GitHub.