Broken pipe, explained

A broken pipe occurs when a process writes to a pipe (or socket) whose reading end has been closed. The writer receives the signal SIGPIPE, which kills it by default, or the error EPIPE if it handles the signal itself. The most familiar sighting is completely benign: some-command | head -5 prints five lines and exits, closing the pipe, and the producing command, still writing, is stopped with a broken pipe. The pipeline worked exactly as designed; the message is the mechanism, not a malfunction.

Where it appears

  1. Pipelines truncated on purpose: head, grep -m1, closing a pager's (less) window early; the producer gets SIGPIPE when it writes the next block.
  2. Programs that report it as an error: tools written in languages that convert SIGPIPE to an exception, Python's BrokenPipeError being the common one, which can also print a second, confusing error at shutdown (“Exception ignored”) when the interpreter flushes standard output into the same closed pipe.
  3. Shell scripts under set -o pipefail: a pipeline reports failure because one member died of SIGPIPE, even though the overall job (show the first lines) succeeded; the script's status logic has to account for it explicitly.
  4. Network services: the socket version of the same event, a client that disconnected mid-response; servers log it as broken pipe (Java) or EPIPE (Node) and it is judged by frequency, not existence.

What to do, by situation

  1. In an interactive pipeline, nothing: the command you truncated was stopped cleanly. If a tool's error text bothers you, redirect its stderr for that invocation, understanding the semantics are unchanged.
  2. In Python command-line tools, the standard treatment is to catch BrokenPipeError, redirect the final flush to devnull (os.dup2), and exit quietly; Python's documentation describes this pattern because a CLI tool should behave like other Unix filters.
  3. In scripts with pipefail, decide intentionally: tolerate the specific producer's SIGPIPE status (141) where truncation is expected, rather than dropping pipefail for the whole script and losing its real protections.
  4. When it is frequent and unprompted (no truncation involved), investigate the disappearing reader: a downstream service restarting, a proxy closing idle connections, a client with a short timeout; the pipe is reporting another component's behavior.

Common questions

Is a broken pipe an error in my data? No. It is about the channel, not the content: the reader closed early. Data written before the close arrived normally; data after it had nowhere to go.

Why does the exit code show 141? Shells report a process killed by signal N as 128 + signal number; SIGPIPE is 13, hence 141. Seeing 141 for the left side of a truncated pipeline is expected and is how scripts can recognize this exact case.

How is this different from the Java broken pipe? Same operating-system event (EPIPE). On this page the context is shells and pipelines, where it is usually intentional truncation; in servers it is client disconnects. The judgment differs, the mechanism is one.

Related errors

Broken pipe (Java) · Segmentation fault · No such file or directory