Linux system errors
Broken Pipe
Reviewed for reference consistency: August 11, 2026
a write failed because the pipe's read end had already closed
What 32 Means
The 32 error on the Linux system errors indicates broken pipe — a write failed because the pipe's read end had already closed. This typically occurs due to a write to a pipeline stage whose reader exited (head is the everyday case).
Exit code 32 corresponds to EPIPE, 'Broken pipe'. A write into a pipe or socket requires a live reader on the other end; when the reader is gone, the kernel rejects the write with errno 32. The same event also raises SIGPIPE — exit code 141 is the shell's view of that signal, and EPIPE is the errno a program sees when it chose to ignore the signal and handle the failure in code.
How to fix 32
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Read the per-stage pipeline statuses
After a pipeline completes, PIPESTATUS lists one status per stage — the reader's number and the writer's number together tell which side ended the story.
./generate_rows | head -n 5; echo ${PIPESTATUS[@]}Make the pipeline surface writer failures
With pipefail, the pipeline's own exit status reflects a failed producer instead of the consumer's success masking it.
set -o pipefail; ./generate_rows | head -n 5
Technical Background
EPIPE is the quiet twin of exit code 141. Behind both sits a single kernel decision: a write arrived for a pipe or socket whose read end no longer exists. The default ending is dramatic — SIGPIPE, no handler, process gone, shell prints 141. But the kernel offers an alternative contract: ignore the signal, and the same failed write returns errno 32 like any other error.
That alternative is why managed runtimes behave differently. Python and Java start life with SIGPIPE ignored precisely so that a dead client connection becomes an exception a server can catch, log, and move past, instead of a death. The errno is the manageable form of the event; the signal is the fatal form.
For services, EPIPE on client sockets is routine traffic — connections drop mid-response all the time, by design of the networks involved. The errno's presence in logs is usually evidence of correct handling rather than a fault: the server noticed, recorded, and kept serving.
Common Causes
- A write to a pipeline stage whose reader exited (head is the everyday case)
- A server writing a response to a socket whose client disconnected seconds earlier
- A daemon that ignores SIGPIPE receiving the errno on its first write after peer death
Typical Scenarios
- A Python service logging a BrokenPipeError traceback after writing to a closed client socket
- A Java application receiving an IOException on a connection the peer terminated mid-response
- A producer in a shell pipeline surviving as a process (SIGPIPE ignored) and recording the errno instead
What to Know
Pipeline-side, the per-stage exit statuses reveal which end of the pipe ended the story. Service-side, frequency matters: scattered EPIPE entries track ordinary client churn, while a sudden cluster points at a network event worth dating.
Frequently Asked Questions
Common questions about Linux 32 error
They are one event with two audiences. A write to a broken pipe raises SIGPIPE and would return EPIPE; the default signal disposition kills the process first, so the shell shows 141. Programs that ignore SIGPIPE live on to see the errno — and exit 32 if they then exit with it.
Their runtimes start with SIGPIPE ignored, so the kernel delivers the errno rather than the signal. The same broken pipe that ends a C program with 141 surfaces in Python as BrokenPipeError or in Java as an IOException.
Treat it as routine: client disconnections mid-response are normal internet weather. The write fails, the connection object is cleaned up, and the service continues — which is precisely why the runtime ignores SIGPIPE for you.
Related Error Codes
Broken Pipe — the process wrote into a pipe whose reader is already gone
Bad File Descriptor — the descriptor number is not open in this process's table
Too Many Open Files — the process hit its per-process descriptor ceiling
Invalid Exit Argument — script exited with an out-of-range status or terminated by a signal
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git paused the merge because it cannot automatically resolve overlapping changes.
Git aborted the merge to protect uncommitted changes in your working directory.
Git prevented a branch switch because it would overwrite unsaved changes in your working directory.
Git aborted the merge because it would overwrite untracked files in your working directory.