fix(delete): handle already-exited processes during force-delete

[Yashika0724]

What changed

killProcess()

• Treat ESRCH from the initial SIGKILL as a successful outcome.
• A force-delete can race with a guest shutdown or a previous kill attempt, leaving the VMM process already exited by the time killProcess() runs. In that case syscall.Kill(pid, SIGKILL) returns ESRCH, which currently propagates as an error even though the process is no longer running.

delete --force

• Continue with Delete() even if Kill() returns an error.
• The purpose of --force is to reclaim runtime state. Returning early from the force-delete path can leave the container state directory behind even when the target process is already gone.

Reproducer

One way to reproduce this is:

1. Start a unikernel workload.
2. Let the VMM exit on its own (or have it exit just before delete --force runs).
3. Run urunc delete -f <id>.

Before this change, Kill() may return ESRCH and the delete operation exits early.

After this change, an already-exited process is treated as a successful kill and cleanup proceeds normally.

Notes

This change only special-cases ESRCH ("no such process"). Other kill failures continue to be returned and logged as before.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	1b26bc7
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/6a26628b23aa6c0008d931b9

[Yashika0724]

Hi @cmainas,

While tracing the force-delete path, I noticed that killProcess() returns ESRCH when the VMM has already exited before the initial SIGKILL, causing delete -f to exit before cleanup runs.

This change treats that case as a successful outcome and allows the force-delete path to continue with cleanup. Other kill errors remain unchanged.

Please let me know if you'd prefer a different approach or any changes to the implementation.

[Yashika0724]

Update: I've rebased onto main to resolve the conflict. It turns out the killProcess() ESRCH handling described above was independently merged via #476 (commit e4e15bb) while this PR was open, so that part is now redundant and has been dropped from the diff.

What remains is the change in cmd/urunc/delete.go: previously, if unikontainer.Kill() returned any error during a forced delete, the command would abort before running cleanup. This change logs the error and proceeds with Delete() regardless, so --force reliably reclaims runtime state even when the kill itself fails for reasons other than the process already being dead (which is now handled at the killProcess level by #476).

Happy to adjust the approach if you'd prefer a narrower error check instead of a blanket log-and-continue.