tinyhumansai/openhuman · error

command failed with status {status}

Error message

command failed with status {status}

What it means

run_checked is the platform::service helper that runs service-management commands (launchctl/systemctl/sc style) and waits for exit; any non-zero exit status — including signal termination on Unix, which the ExitStatus Display shows — produces this bail. The child's stderr is inherited, so the human-readable reason is not in the error, only the status.

Source

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

        .replace('\'', "'")
}

/// Suppress conhost allocation for Windows command spawns. Without this,
/// every `schtasks /Query` polled by service status checks flashes a
/// console — visible to users (#1475 follow-up to #731 + #1338).
#[cfg(windows)]
fn no_window(cmd: &mut Command) {
    cmd.creation_flags(0x0800_0000); // CREATE_NO_WINDOW
}

#[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) => {

View on GitHub (pinned to 7491200858)

Solutions

  1. Re-run the failing service command manually to see its stderr — e.g. `systemctl --user status openhuman-core` on Linux or `launchctl print gui/$(id -u)/<label>` on macOS.
  2. Fix the environment: ensure a systemd user session exists on Linux (`loginctl enable-linger $USER` for headless), proper LaunchAgents permissions on macOS.
  3. Verify the daemon executable resolves (OPENHUMAN_CORE_BIN override or sibling-binary lookup in common.rs) so the manager has something to launch.
  4. Retry after the environment fix — a unit-not-yet-loaded race can surface the same status.

Example fix

// before
run_checked(&mut cmd)?;

// after — include the command line in the error so the failure is reproducible manually
let program = cmd.get_program().to_string_lossy().to_string();
run_checked(&mut cmd)
    .map_err(|e| anyhow::anyhow!("{e}; while running `{program}` — rerun it manually to see stderr"))?;
Defensive patterns

Strategy: try-catch

Validate before calling

// Linux: is there actually a user systemd session to talk to?
fn systemd_user_available() -> bool {
    std::path::Path::new("/run/systemd/system").exists()
        && std::env::var("XDG_RUNTIME_DIR").is_ok()
}

Try / catch

Catch the status error, log the program and args, then rerun the same command once with .output() to capture stderr for the user; distinguish 'environment lacks the service manager' (skip with a warning) from 'command genuinely failed' (surface the error).

Prevention

When it happens

Trigger: Installing or starting the background service where the underlying command exits non-zero: systemctl on a system without systemd or with the unit masked; launchctl failing in restricted macOS contexts; sc failing on permission-denied; the daemon binary unresolvable is a different (earlier) error, so this specifically means the command ran and failed.

Common situations: Running service install inside a container without systemd; headless Linux sessions lacking a user systemd instance (no enable-linger); macOS LaunchAgents directory restricted; partially-completed prior installs leaving the manager in a bad state.

Related errors


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