[rahul05ranjan]

Description

urunc start returns an error when a poststart hook fails, but leaves the container running: startUnikontainer() (cmd/urunc/start.go) sets the running state and then returns ExecuteHooks("Poststart") directly, without stopping the monitor. The guest keeps running, state.json still reports running, and since the monitor's init process still answers, a plain urunc delete (without --force) is refused with cannot delete running container — the container is left alive by a start that reported failure.

The OCI runtime spec is explicit about this case:

If any poststart hook fails, the runtime MUST generate an error, stop the container, and continue the lifecycle at step 12.

(runtime.md, container lifecycle step 9.) runc kills the container on this path.

The fix mirrors what urunc delete --force already does in the same situation (cmd/urunc/delete.go): stop the monitor with unikontainer.Kill(), which stops the VMM process and returns once the monitor has exited, leaving the release of the remaining resources to the delete transition — exactly "stop the container and continue with delete". The hook error is still returned; if the stop itself fails, both errors are joined so the caller sees the compound failure. Kill() on a monitor that never started is a no-op (State.Pid <= 0), so the path is safe for any state the start sequence could have reached. Both entry points that execute poststart hooks (urunc start and urunc run, which calls startUnikontainer) get the behavior.

Related issues

• Fixes urunc start leaves the guest running when a poststart hook fails #1172

How was this tested?

• Static trace on 4f6b879: the previous return unikontainer.ExecuteHooks("Poststart") was the only error path in startUnikontainer after SetRunningState() that left the monitor alive (the AwaitMsg/startReexec failures happen before the monitor reports a successful start and the reexec/monitor process tears down on its own); Delete() refuses via isRunning() (syscall.Kill(Pid, 0) on the monitor pid), which is why the stopped-then-delete sequence is required rather than only a state write — urunc never persists a stopped status and delete --force already relies on Kill() for exactly this outcome.
• Go toolchain, a solo5/mirage bundle and a VMM are not available on this machine, so neither make lint nor the e2e suites (test_ctr/test_nerdctl/test_docker/test_crictl) were run locally. The change is a 12-line, single-file error path that reuses an existing, already-tested method; the runtime verification for this fix is the reproduction in urunc start leaves the guest running when a poststart hook fails #1172 (a bundle with a failing poststart hook, then urunc start + urunc delete without --force).

LLM usage

GLM (Z.ai, model glm-5.3, via OpenRouter) assisted in analyzing the issue, reading the runtime spec and preparing this change; the diff was reviewed line by line against the spec text quoted above and against urunc's own delete --force path before opening.

Checklist

• I have read the contribution guide.
• The linter passes locally (make lint). — no Go toolchain on this machine; single-file change in gofmt style.
• The e2e tests of at least one tool pass locally (make test_ctr, make test_nerdctl, make test_docker, make test_crictl). — needs a solo5 VMM and a unikernel image, not available here; CI will run the suite once labeled.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	7c4059c
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/6ae17b2e129dc8f399fb64ed