jdx/mise · error

{engine_bin} exited abnormally: {status:?}

Error message

{engine_bin} exited abnormally: {status:?}

What it means

After the container finishes, mise inspects the exit status of the `podman run`/`docker run` it spawned. A normal non-zero exit code is propagated as mise's own exit code (request_exit). This bail fires only when the status has NO code and is not successful — on Unix that means the engine client itself was terminated by a signal (OOM-kill, SIGKILL, SIGSEGV), and the message Debug-formats the ExitStatus.

Source

Thrown at src/cli/oci/run.rs:216

                Ok(out) if out.status.success() => {}
                Ok(out) => {
                    // Don't fail the overall command — just note it; a
                    // failing rmi usually means the image is still in use
                    // (e.g. another concurrent run) or was already deleted.
                    let stderr = String::from_utf8_lossy(&out.stderr);
                    debug!("{engine_bin} rmi {image_ref} failed: {stderr}");
                }
                Err(e) => debug!("failed to spawn {engine_bin} rmi: {e}"),
            }
        }

        let status = run_result?;
        if let Some(code) = status.code() {
            if code != 0 {
                return Err(crate::request_exit(code));
            }
        } else if !status.success() {
            bail!("{engine_bin} exited abnormally: {status:?}");
        }
        Ok(())
    }
}

fn select_engine(requested: Engine) -> Result<Engine> {
    match requested {
        Engine::Podman => {
            if file::which("podman").is_some() {
                Ok(Engine::Podman)
            } else {
                bail!("--engine podman requested but `podman` was not found on PATH")
            }
        }
        Engine::Docker => {
            if file::which("docker").is_none() {
                bail!("--engine docker requested but `docker` was not found on PATH");
            }

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

  1. Check for an OOM kill: `dmesg | grep -i 'killed process'` or `journalctl -k`
  2. Free memory/disk (`podman system prune`, `docker system prune`) and rerun
  3. If reproducible, run the container directly (`podman run ...`) to isolate whether the engine itself crashes
Defensive patterns

Strategy: try-catch

Type guard

// Rust: narrow an ExitStatus to 'killed by signal' (no exit code, not success)
fn terminated_by_signal(status: &std::process::ExitStatus) -> bool {
    status.code().is_none() && !status.success()
}

Try / catch

# bash wrapper: distinguish signal death from task failure
if ! mise oci run img -- ./task; then
  code=$?
  if [ "$code" -ge 128 ]; then
    echo "engine/mise killed by signal $((code-128)); checking OOM..." >&2
    dmesg -T | grep -i 'killed process' || true
  fi
  exit "$code"
fi

Prevention

When it happens

Trigger: The kernel OOM-killer sends SIGKILL to the podman/docker client during a heavy container run; someone runs `kill -9` on the mise or engine process; the engine binary crashes (segfault) mid-run. The container's own non-zero exit does NOT produce this error.

Common situations: CI runners with tight memory limits where large tool layers + container exhaust RAM; flaky sandboxed environments killing long processes; disk-full conditions crashing container storage code.

Related errors


AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/ed752946a3bf59af. Report an issue: GitHub.