A Go daemon exits its accept loop on any error from net.Listener.Accept. What breaks?

## Why the naive loop is wrong ```go for { conn, err := ln.Accept() if err != nil { return err // every failure is fatal } go handle(conn) } ``` This reads like careful error handling and behaves like a single point of failure. `Accept` sits at the boundary between your process and everything outside it, and errors there are not all the same kind of event: - **The listener was closed.** Your own shutdown path did it. Returning is correct. - **A per-connection failure.** The peer connected and then disappeared before you accepted it, or the connection was reset during the handshake. Nothing about the server is broken; one client is gone. - **A resource shortage.** The process is momentarily out of descriptors. Every *existing* connection is still fine and the situation usually clears. - **A genuinely permanent failure.** Rare in practice on a bound listener. A loop that returns on all four turns a lost client into an outage. The daemon exits, the port goes away, and if the process is supervised it flaps. ## The triage that works ```go for { conn, err := ln.Accept() if err != nil { if errors.Is(err, net.ErrClosed) { return nil // deliberate shutdown } log.Printf("accept: %v", err) time.Sleep(10 * time.Millisecond) continue } go handle(conn) } ``` Three decisions are encoded there. **`net.ErrClosed` is the shutdown signal.** Since Go 1.16 the error returned by operations on a closed listener or connection wraps this sentinel, so `errors.Is` is the supported test. Before that, code compared `err.Error()` against the string `"use of closed network connection"` — you still see it, and it is now an anti-pattern: an unexported error's text is not API. **The sleep is not superstition.** An error that recurs immediately — the descriptor limit is the usual one — makes the loop a spin loop that consumes a whole core while logging thousands of identical lines a second. Even 5–10 ms of pause turns that into a survivable degraded state. The standard library's `http.Server.Serve` does the same thing more carefully, starting at a small delay and doubling it up to a ceiling, then resetting after a successful accept. Copying that shape is reasonable for a hand-rolled server. **Don't use `Temporary()`.** The `net.Error` interface has `Timeout() bool` and `Temporary() bool`, and `Temporary` is documented as deprecated: which errors count as temporary was never specified consistently, and code that branches on it is making a decision on a coin flip. `Timeout()` is still meaningful, but a listener with no deadline set does not produce timeouts. ## Shutting the loop down deliberately Because `Accept` blocks, you cannot poll a flag between iterations — the goroutine is parked inside the call. The way out is to close the listener from elsewhere: ```go go func() { <-ctx.Done() ln.Close() // unblocks Accept with net.ErrClosed }() ``` Closing the listener stops new connections; it does **not** touch connections already accepted, which keep running until their handlers finish. That separation is usually what you want for graceful shutdown: stop taking work, drain what you have. If you are running `http.Server` over your own listener via `Serve(ln)`, the equivalents are `Shutdown(ctx)` — stop accepting, then wait for in-flight requests — and the sentinel `http.ErrServerClosed`, which `Serve` returns afterwards and which you should not treat as a failure. ## What an interviewer is listening for The distinction between fatal and transient, named concretely rather than as a principle; `errors.Is(err, net.ErrClosed)` rather than a string compare; the backoff and *why* it exists; and awareness that `Temporary` is deprecated. Bonus points for saying that closing the listener is the only way to unblock a parked `Accept`, and that doing so leaves established connections alone.