Introduction

errno 32, usually reported as Broken pipe, means your program tried to write to a pipe or socket after the reading side had already closed it. In other words, the problem is not that your write call is malformed. The other side stopped listening.

That is why there is no magic switch that "prevents broken pipe forever." The real goal is to design the write path so your program either avoids pointless writes after disconnects or handles the failure cleanly when the peer goes away.

What Actually Causes a Broken Pipe

On Unix-like systems, if a process writes to a closed pipe, the kernel sends SIGPIPE. In many runtimes, that eventually appears as an exception or error such as BrokenPipeError, EPIPE, or errno 32.

Typical examples include:

• writing to a network socket after the client disconnected
• writing to stdout when the next command in a shell pipeline exited early
• writing to a subprocess pipe after the subprocess already terminated

A classic shell example is piping output into head, which closes the pipe after reading enough lines.

You Usually Handle It, Not Eliminate It

The most practical strategy is:

1. stop writing once the peer is gone
2. catch the error and exit or clean up gracefully
3. avoid buffering or retry logic that keeps writing into a dead connection

In Python, a simple network-style example looks like this:

1import socket
2
3server = socket.socket()
4server.bind(("127.0.0.1", 5000))
5server.listen(1)
6conn, _ = server.accept()
7
8try:
9    conn.sendall(b"hello\n")
10except BrokenPipeError:
11    print("client disconnected")
12finally:
13    conn.close()
14    server.close()

This does not stop the client from disconnecting. It stops your program from crashing badly when that happens.

The Common Pipeline Case

Broken pipe is very common when a Python script prints a lot of output and the downstream command exits early.

Example:

python produce_lines.py | head -n 5

If produce_lines.py keeps writing after head has exited, the script may hit a broken pipe. A clean Python pattern is:

1import sys
2
3try:
4    for i in range(1000000):
5        print(i)
6except BrokenPipeError:
7    try:
8        sys.stdout.close()
9    finally:
10        pass

This is especially relevant for CLI tools that are expected to behave nicely in Unix pipelines.

Network Code: Stop Sending After Disconnects

In socket servers or clients, broken pipe usually means the remote side closed the connection. The fix is not to retry the same write blindly. The fix is to treat the connection as dead.

A pattern like this is safer:

1def safe_send(conn, data: bytes) -> bool:
2    try:
3        conn.sendall(data)
4        return True
5    except BrokenPipeError:
6        return False

Once safe_send returns False, remove that connection from your active set and stop writing to it.

Subprocess Pipes Need Lifecycle Awareness

If you write into a child process through stdin, you can also hit broken pipe when the child exits first.

1import subprocess
2
3proc = subprocess.Popen(["cat"], stdin=subprocess.PIPE, text=True)
4proc.stdin.write("hello\n")
5proc.stdin.close()
6proc.wait()

This is fine as long as the child is still alive. If the child exits before the write, the parent can get BrokenPipeError.

The prevention strategy is to manage process lifetime carefully and avoid writing after the child has already terminated.

What About SIGPIPE?

In lower-level Unix programs, developers sometimes ignore SIGPIPE and handle EPIPE manually. Some runtimes already do part of this for you. In application code, the important point is usually not signal theory but practical behavior: catch the write failure and stop treating the stream as usable.

Suppressing the signal without handling the dead connection properly only hides the symptom.

Common Pitfalls

The biggest pitfall is retrying the exact same write after a broken pipe without re-establishing the connection or reopening the stream. Once the other side is gone, repeating the write does not fix anything.

Another common issue is assuming this error is always a network problem. It can just as easily come from shell pipelines or subprocess communication.

Developers also sometimes log the exception and keep the dead socket in a connection pool or list. That guarantees more broken writes later.

Finally, do not confuse prevention with suppression. Ignoring SIGPIPE or swallowing the exception is not enough unless your program also stops writing to the dead destination.

Summary

• 'errno 32 means your program wrote to a pipe or socket whose reader had already closed.'
• You usually handle broken pipe gracefully rather than preventing the peer from ever disconnecting.
• In network code, treat the connection as dead and stop writing to it.
• In shell pipelines and subprocesses, expect early reader shutdown and handle it cleanly.
• Retrying the same write blindly is usually the wrong response.