fix(hypervisors): treat zombie VMM as dead in killProcess to avoid 2s deadlock

[Atishyy27]

Problem

Closes #790.

When a VMM (Firecracker/QEMU/HVT/SPT/Cloud Hypervisor) terminates it enters the zombie (defunct) state until its parent — the containerd shim — reaps it with waitpid. killProcess sends SIGKILL and then polls unix.Kill(pid, 0) waiting for ESRCH:

for {
    if err := unix.Kill(pid, 0); err != nil {
        if errors.Is(err, unix.ESRCH) { break } // never reached for a zombie
        ...
    }
    if time.Now().After(deadline) {
        return fmt.Errorf("timeout waiting for pid %d to die", pid)
    }
    time.Sleep(100 * time.Millisecond)
}

unix.Kill(pid, 0) returns nil for a zombie (it still exists in the process table), so the loop never sees ESRCH. Every forced-cleanup path (e.g. urunc delete --force) therefore blocks for the full 2-second timeout and then returns a bogus "timeout waiting for pid to die" error, even though the VMM is already dead.

Fix

Detect the zombie state via /proc/<pid>/stat and treat it as dead, breaking out of the loop immediately:

• isZombie(pid) reads the stat file (missing file → already reaped → treated as gone).
• statIsZombie([]byte) is a pure helper that reads the process state field. It parses the state as the first byte after the final ), so a comm field containing spaces or ) cannot corrupt parsing.

Result: forced cleanup returns as soon as the VMM is dead instead of waiting ~2000 ms, and no longer reports a false timeout error.

Tests

TestStatIsZombie covers zombie/running/sleeping states, a comm with embedded spaces and ), and malformed/empty input.

Verification

go build, go vet and test compilation pass (cross-compiled to linux/amd64). The pure statIsZombie logic was also run directly against all test cases. CI will run the full suite on Linux.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	763c6a8
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/6a4ebffcb7dea600087c1495