Why does a child started with os/exec hang forever when you write to cmd.StdinPipe() but never close it?

## The child is not waiting for you to stop; it is waiting for a close When you hand a child process its input through `cmd.StdinPipe()`, you get back an `io.WriteCloser`. That value is the parent's write end of an operating-system pipe. The child process holds the matching read end as its file descriptor 0. A great many command-line programs are *filters*: they read their standard input until it ends and only then finish. `sort` cannot emit its first line until it has seen the last one. `wc` cannot report a count until counting stops. A compressor may emit output as it goes, but it will not exit until its input is done. "Input is done" has exactly one meaning on a pipe: a read returns zero bytes, which the kernel does only once **every** write end of that pipe has been closed. Your program is holding a write end. Until you close it, the child's read blocks. The child does not exit. `cmd.Wait` — which waits for exactly that — does not return. And `cmd.Wait` is the thing that would eventually close the pipe for you, so the two sides are waiting on each other. The program does not crash, does not log anything, and does not use CPU; it simply stops. ## The fix, and where to put the Close ```go stdin, err := cmd.StdinPipe() if err != nil { return err } if err := cmd.Start(); err != nil { return err } if _, err := io.Copy(stdin, payload); err != nil { stdin.Close() return err } if err := stdin.Close(); err != nil { // the child now sees end of file return err } return cmd.Wait() ``` Two details matter about placement. **Close before `cmd.Wait`, not after.** A `defer stdin.Close()` at the top of the function looks tidy and is a classic version of this bug: deferred calls run when the function returns, which is *after* `cmd.Wait` has already blocked forever. The close has to happen on the path, or inside the goroutine that does the writing. **Close on the error path too.** If the copy fails halfway and you return without closing, you leak the same hang into whatever cleanup follows. A redundant `Close` is harmless: the writer os/exec hands you closes once, so if `cmd.Wait` later tries again nothing bad happens, and your own second call is a no-op rather than an error you must reason about. ## The shape that removes the trap If the input is already in hand — a byte slice, a string, an open file — do not take the pipe at all: ```go cmd.Stdin = bytes.NewReader(payload) ``` When `cmd.Stdin` is a reader that is not an `*os.File`, os/exec creates the pipe itself, starts a goroutine copying your reader into it, and closes the write end when that copy reaches end of file. The child gets its end-of-file automatically. When `cmd.Stdin` is an `*os.File`, that descriptor is passed straight through and there is no pipe of os/exec's making at all. And when `cmd.Stdin` is nil the child reads from the null device, so it sees end of file immediately — which is why a forgotten `cmd.Stdin` makes filters return empty output rather than hang. Take `cmd.StdinPipe()` when the input is *generated* rather than already available: you are streaming records as you compute them, forwarding another stream, or writing a request and then waiting on a reply. ## The second hang hiding behind the first Closing stdin is necessary but not always sufficient. If the child produces substantial output while you are still writing its input, you must be draining that output at the same time, because the child blocks once its output pipe fills and then stops reading your input. The usual safe arrangement is: one goroutine writes the payload and closes stdin with a deferred `Close`, while another goroutine (or os/exec's own, if you assigned a writer to `cmd.Stdout`) reads the output. Get both right and the pipeline runs; get only the close right and a large payload can still stall. ## How it looks when it happens The symptom is a process that hangs with no error, often only for certain inputs. A goroutine dump — from `go test` hitting its `-timeout`, or from sending SIGQUIT to the stuck binary — shows the parent parked in `cmd.Wait`, and the child alive in the process table doing nothing. Seeing `Wait` on the stack with a live child is the tell: ask what the child is still waiting for, and end of file on standard input is the first candidate.