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
- Check for an OOM kill: `dmesg | grep -i 'killed process'` or `journalctl -k`
- Free memory/disk (`podman system prune`, `docker system prune`) and rerun
- 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
- Give CI runners headroom above the container's memory request so the engine client is never OOM-killed
- Exit codes >= 128 in wrappers mean signals — treat them as infrastructure failures, not test failures
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
- {}: does not look like an OCI image layout (missing index.js
- --engine podman requested but `podman` was not found on PATH
- --engine docker requested but `docker` was not found on PATH
- no supported container engine found. Install podman or docke
- podman pull failed: {}: {stderr}
AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17).
Data as JSON: /api/errors/ed752946a3bf59af.
Report an issue: GitHub.