Why must a Go program still call cmd.Wait after cmd.Process.Kill has terminated the child?

## Kill is a request, not an event `cmd.Process.Kill()` asks the operating system to terminate the process. On Unix that means delivering SIGKILL; on Windows it terminates the process. In both cases the call returns as soon as the request has been made, not when the process has finished dying. The child may still be executing for a short while afterwards — the kernel has to tear down its address space, close its descriptors, and release its locks. That asynchrony is the first reason `Wait` is not optional. Code like this is a race: ```go _ = cmd.Process.Kill() os.RemoveAll(workdir) // the child may still hold files here ``` On Linux the removal usually appears to succeed while the child keeps writing to descriptors it already holds; on Windows it can fail outright because files are still open. Waiting first is what makes "the child is gone" true. ## Zombies and reaping The second reason is the Unix process model. When a process exits, the kernel keeps a small record of it — its exit status and resource usage — so that its parent can find out what happened. Until the parent collects that record, the entry stays in the process table in the `Z` (zombie) state. It consumes no memory or CPU, but it occupies a PID slot, and the system has a finite number of them. The act of collecting that record is *reaping*. In Go it is `cmd.Wait` (or `cmd.Run`, which is `Start` followed by `Wait`, or `cmd.Output` and `cmd.CombinedOutput`, which also wait internally). A program that starts commands in a loop and never waits accumulates one zombie per command. On a long-running server — a job runner, a webhook handler that shells out, a scheduler — that reaches the PID limit and then nothing on the host can fork. Zombies vanish when the parent itself exits, because the orphaned records are re-parented to PID 1, which reaps them. That is why the bug so often hides in tests and short scripts and only appears in the daemon. ## What Wait does besides reaping `Wait` is also the point at which `os/exec`'s own bookkeeping finishes. When you assign an `io.Writer` such as a `bytes.Buffer` to `cmd.Stdout`, the package runs a goroutine copying the child's output into it; `Wait` is what waits for that copying to complete, which is why reading the buffer before `Wait` returns is unsafe. `Wait` also closes the descriptors the package opened on your behalf, and it populates `cmd.ProcessState`. That `ProcessState` is where the outcome lives. `ProcessState.Exited()` reports whether the process exited normally, and `ProcessState.ExitCode()` returns -1 rather than a real code when the process was terminated by a signal — which is exactly the case after a kill. If you want to report "killed" distinctly from "exited with status 2", that -1 plus your own knowledge that you sent the kill is how you do it. ## The rules around Wait A few constraints matter in review: - `Wait` must be called exactly once per command; a second call returns an error rather than a second status. - It must follow a successful `Start`. Calling it on a command that never started is a mistake. - After `Wait` has returned, the process is fully released. A later `cmd.Process.Signal` on it returns `os.ErrProcessDone` rather than reaching anything. - `cmd.Run`, `cmd.Output` and `cmd.CombinedOutput` all wait for you. The manual `Start`/`Wait` pair is only needed when you want to do something while the child runs — including killing it. ## The shape that gets it right When you start a command manually, pair the start with the wait immediately, and let the kill be a separate concern: ```go if err := cmd.Start(); err != nil { return err } defer cmd.Wait() // always reap, whatever else happens ``` In a program that kills deliberately, the more careful form captures the wait error, because that is where you learn what actually happened to the child — whether it exited on its own before your kill landed, or died from the signal. Using `exec.CommandContext` does not change any of this. Context cancellation triggers the kill; it does not reap. The package still expects your program to call `Wait`, and the whole cleanup path — descriptors, copying goroutines, the process-table entry — hangs off that call. ## Why this shows up in interviews It is a good question because it separates people who have used `cmd.Run` from people who have operated a program that starts processes. The `Run` path hides `Wait` entirely, so the requirement is invisible until you need to kill something mid-flight and reach for `Start` — and that is precisely the code path where forgetting it costs a host its PID space.