Exit code 141: The process was terminated by SIGPIPE — it wrote to a closed pipe or socket

141 is 128 + 13, meaning SIGPIPE. The process wrote to a pipe or socket whose reader had gone away. The default action for SIGPIPE is to terminate, which surprises people who expected an error return instead.

Applies to: All Kubernetes versions, Linux nodes

What it means

Signal 13 is SIGPIPE, sent when a process writes to a pipe or socket with no reader at the other end. Its default disposition is to terminate the process silently — no message, no stack trace, just a sudden exit. This is deliberate Unix design for shell pipelines, where a producer should stop when its consumer exits. It becomes a problem in servers, where a client disconnecting mid-response is completely normal and should not kill anything. Most modern runtimes and HTTP libraries ignore SIGPIPE and surface an EPIPE error instead, so a container exiting 141 usually means either a shell pipeline in an entrypoint script or native code that did not install the usual handler.

Most common causes

• A shell pipeline in an entrypoint or sidecar where a downstream command exits early — piping into head is the classic example.
• A server writing a response to a client that has already disconnected, in code that has not disabled SIGPIPE.
• A logging process writing to a pipe whose reader has died.
• A sidecar exiting and taking down a pipeline it was part of.
• A backup or export job piping to a command that failed partway through.

How to diagnose it

1. Look for a shell pipeline in the container's command or entrypoint. A pipeline in command: ["sh", "-c", …] is the first place to check.
2. Check whether the exit correlates with client disconnections or with load balancer timeouts.
3. Read the logs for what the process was writing when it died — with SIGPIPE there is usually no error message, so the last successful line is the clue.
4. Check whether a sidecar or a co-process exited just before the main container.

How to fix it

1. In servers, ignore SIGPIPE and handle EPIPE as an ordinary write error. Almost every language has a one-line way to do this.
2. In shell pipelines, avoid consumers that exit early, or set pipefail deliberately so the behaviour is explicit rather than accidental.
3. If a sidecar is part of a pipeline, make the ordering explicit rather than relying on both processes staying alive.
4. For long-running exports, write to a file and process it afterwards rather than streaming through a pipeline that can break.

Notes

SIGPIPE produces no output at all by default, so a container exiting 141 with a completely clean log is the expected presentation rather than a sign that logging is broken.

Related

• Exit code 143 — Terminated by SIGTERM
• Exit code 1 — General application error

Sources

• Linux manual page — signal(7)
• GNU Bash Reference Manual — Exit Status
• Kubernetes documentation — Debug Running Pods