Debian 13 “Broken pipe” errores: cuándo son inofensivos y cuándo son tu primera advertencia (caso #75)

Qué significa realmente “broken pipe” en Debian 13

En Debian 13, como en cualquier otro Linux moderno, “broken pipe” suele ser tu aplicación exponiendo una condición clásica de UNIX:
EPIPE (errno 32). En términos sencillos: tu proceso intentó un write() (o envío equivalente)
a una tubería o socket que ya no tiene un lector en el otro extremo.

De dónde viene el mensaje

• Las aplicaciones imprimen “Broken pipe” cuando capturan EPIPE y lo registran (Go, Java, Python, Ruby, Nginx, Apache, clientes de PostgreSQL, y más).
• Los pipelines de shell a veces lo muestran cuando un consumidor downstream sale antes de tiempo (piensa en head) y el upstream sigue escribiendo.
• Las bibliotecas pueden convertir EPIPE en una excepción (por ejemplo, java.io.IOException: Broken pipe, BrokenPipeError: [Errno 32] en Python).
• Señales: por defecto, escribir en una tubería cerrada puede desencadenar SIGPIPE que termina el proceso a menos que se maneje/ignore. Muchos servidores de red ignoran SIGPIPE específicamente para evitar morir y en su lugar registran EPIPE.

El detalle operativo clave: EPIPE es el escritor descubriendo que el par se fue. No prueba que el escritor esté defectuoso,
y no prueba que la red está mala. Prueba un desajuste de ciclo de vida: un lado sigue escribiendo y el otro lado ya terminó.

Broken pipe vs. connection reset: por qué importa la distinción

Los ingenieros a menudo agrupan “broken pipe” con “connection reset by peer”. Están relacionados pero no son idénticos.
“Connection reset” suele ser ECONNRESET: el par (o un middlebox) envió un RST TCP, cerrando la conexión abruptamente.
“Broken pipe” suele ser EPIPE cuando escribes después de que el par cerró (FIN) y tú ya lo procesaste.

Esa matización importa porque un FIN tras una respuesta es normal para muchos clientes, mientras que una oleada de RSTs puede significar un timeout de proxy, presión en el kernel,
o un proceso de servicio terminado de forma violenta. Debian 13 no cambió TCP, pero los valores por defecto más recientes y versiones nuevas de demonios pueden cambiar
la frecuencia con la que ves estos mensajes.

Una cita que suelo tener en el tablero mental: Werner Vogels (CTO de Amazon) popularizó la mentalidad de fiabilidad—
“Everything fails, all the time” (idea parafraseada). “Broken pipe” suele ser tu primera pequeña postal desde esa realidad.

Ruido inofensivo vs. primera advertencia

Cuándo “broken pipe” suele ser inofensivo

Puedes bajar la urgencia con seguridad cuando todo esto es cierto:

• Se correlaciona con abortos de cliente: usuarios navegando fuera, clientes móviles cambiando de red, pestañas del navegador cerradas.
• Error de baja tasa: un pequeño porcentaje de peticiones, estable en el tiempo, sin tendencia al alza bajo carga.
• Sucede después de que se enviaron la mayoría de cabeceras/cuerpo de la respuesta: clásico “el cliente cerró la conexión mientras se enviaba la respuesta”.
• Es en endpoints con descargas largas: archivos grandes, respuestas en streaming, SSE/websocket-like sin keepalive apropiado.
• Métricas sin daño: p95/p99 de latencia, tasa de 5xx, saturación y profundidades de cola tranquilos.

Ejemplo: Nginx registra broken pipe porque el navegador dejó de leer una respuesta grande. Tu servidor no hizo nada malo;
tu nivel de logs solo es honesto.

Cuándo “broken pipe” es tu primera advertencia

Trátalo como un olor de pager cuando cualquiera de esto sea cierto:

• Picos de tasa durante despliegues: sugiere churn de conexiones, arranques lentos, problemas de readiness o pods antiguos drenando mal.
• Coincide con timeouts: timeouts upstream, timeouts de proxy, timeouts inactivos del balanceador.
• Aparece con presión de memoria/CPU: el servidor se queda atascado, los clientes se rinden y luego los writes impactan sockets muertos.
• Agrupado en peers específicos: una AZ, una puerta NAT, una capa de proxy, un endpoint con almacenamiento.
• Aparece en RPC interno: las llamadas servicio-a-servicio que fallan raramente son “comportamiento de usuario”.
• Se correlaciona con retransmisiones/reset de TCP: sugiere pérdida de paquetes, problemas MTU, presión en conntrack o un mal día de middlebox.

Broma #1: “Broken pipe” es el equivalente en logs de tu compañero diciendo “tenemos que hablar”—puede no ser nada, pero no dormirás hasta entenderlo.

La regla operacional

Si “broken pipe” es mayormente tráfico edge y la salud del servicio está verde, es ruido que puedes domar.
Si es tráfico este-oeste, está aumentando, o viene acompañado de timeouts/5xx, es un síntoma. Persigue la razón subyacente, no la cadena.

Hechos e historia útiles para un postmortem

1. “Broken pipe” viene de las pipes UNIX: escribir en una tubería sin lector históricamente lanzaba SIGPIPE; la expresión precede a los servicios TCP modernos.
2. EPIPE es errno 32 en Linux: por eso ves “Errno 32” en Python y similares.
3. La acción por defecto de SIGPIPE es terminar el proceso: muchos servidores ignoran explícitamente SIGPIPE para sobrevivir desconexiones de clientes.
4. TCP tiene dos modos comunes de cierre: cierre ordenado (FIN) vs. reset abrupto (RST). Firmas de fallo diferentes, culpables diferentes.
5. HTTP/1.1 keep-alive lo hizo más visible: conexiones persistentes aumentaron la superficie para timeouts inactivos y estados half-closed.
6. Los proxies inversos registran “broken pipe” con frecuencia: se sitúan entre clientes y upstreams y son los primeros en notar cuando un lado abandona.
7. Los middleboxes adoran los timeouts: balanceadores, puertas NAT, firewalls y proxies aplican timers de inactividad que las aplicaciones suelen olvidar sincronizar.
8. Linux puede reportar errores de socket tarde: un write puede parecer exitoso localmente y solo reportar fallo más tarde; por eso el momento parece “aleatorio”.
9. “Cliente abortó” no siempre es un usuario: health checks, monitorización sintética, scanners y SDKs agresivos también abren y cierran conexiones.

Guía de diagnóstico rápido

Este es el orden que encuentra cuellos de botella reales rápido. Está optimizado para la realidad de on-call: necesitas una dirección en 10 minutos, no una tesis en 10 horas.

Primero: clasifica dónde ocurre (edge vs. interno)

• Edge / HTTP público: comienza con logs de proxy (Nginx/Apache/Envoy), patrones de abortos de cliente y timeouts.
• RPC interno / base de datos: trátalo como un incidente de fiabilidad hasta que se demuestre lo contrario.
• Scripts de shell / cron: a menudo comportamiento inofensivo de pipeline, pero puede ocultar problemas de salida parcial.

Segundo: correlaciona con timeouts y saturación

• Revisa contadores 499/408/504 (o equivalentes) y timeouts upstream.
• Verifica CPU steal, cola runnable, presión de memoria, IO wait, latencia de disco.
• Revisa retransmisiones/reset de la red.

Tercero: confirma quién cerró primero

• Captura paquetes durante un minuto en el nodo afectado (sí, incluso en 2025, tcpdump sigue ganándose el sueldo).
• Inspecciona configuración de keepalive entre cliente, proxy, balanceador y servidor.
• Busca comportamiento de deploy/drain: readiness gates, drenado de conexiones, shutdown ordenado.

Cuarto: decide la clase de corrección

• Ruido: ajustar logging, reducir stack traces, añadir muestreo y mejorar visibilidad de abortos de cliente.
• Desajuste de timeouts: alinear timeouts inactivos y keepalives; ajustar buffering del proxy.
• Sobrecarga: añadir capacidad, reducir trabajo por petición, arreglar IO lento (almacenamiento o red), añadir backpressure.
• Caídas: arreglar OOM, segfaults, tormentas de reinicio y malas prácticas de despliegue.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que realmente ejecuto en hosts Debian. Cada una tiene tres partes: el comando, qué significa la salida y qué decisión tomas a continuación.
Los comandos asumen root o sudo cuando es necesario.

Task 1: Find the exact error wording and which service emits it

cr0x@server:~$ sudo journalctl -S -2h -p warning..alert | grep -i -E "broken pipe|EPIPE|SIGPIPE" | tail -n 20
Dec 31 09:12:41 api-01 nginx[1234]: *918 writev() failed (32: Broken pipe) while sending to client, client: 203.0.113.10, server: _, request: "GET /download.bin HTTP/1.1"
Dec 31 09:13:02 api-01 app[8871]: ERROR send failed: Broken pipe (os error 32)

Significado: Ahora sabes si es Nginx, la app, un sidecar u otra cosa.
Nginx “while sending to client” grita aborto de cliente; fallos de envío a nivel de app pueden ser downstream (BD, cache, RPC interno).
Decisión: Divide la investigación: patrones de tráfico de borde para Nginx; trazado de dependencias para errores de app.

Task 2: Check if deploys or restarts line up with the spike

cr0x@server:~$ sudo journalctl -S -6h -u nginx -u app.service --no-pager | grep -E "Started|Stopping|Reloaded|SIGTERM|exited" | tail -n 30
Dec 31 08:59:58 api-01 systemd[1]: Reloaded nginx.service - A high performance web server and a reverse proxy server.
Dec 31 09:00:01 api-01 systemd[1]: Stopping app.service - API Service...
Dec 31 09:00:03 api-01 systemd[1]: app.service: Main process exited, code=killed, status=15/TERM
Dec 31 09:00:03 api-01 systemd[1]: Started app.service - API Service.

Significado: El churn de conexiones durante reload/restart puede producir EPIPE cuando los clientes en vuelo pierden su upstream.
Decisión: Si los errores se agrupan alrededor de reinicios, inspecciona shutdown ordenado, drenado de conexiones, readiness y retries del proxy.

Task 3: Look for client-abort status codes at the proxy

cr0x@server:~$ sudo awk '$9 ~ /^(499|408|504)$/ {c[$9]++} END{for (k in c) print k, c[k]}' /var/log/nginx/access.log
499 317
504 12
408 41

Significado: Muchos 499 suelen significar que el cliente cerró temprano (convención de Nginx). 504 sugiere timeout upstream.
408 indica timeout de petición (cliente demasiado lento o timeout de lectura de cabeceras).
Decisión: Si 499 domina con 5xx estables, probablemente sea ruido inofensivo; si 504 sube con EPIPE, persigue latencia/sobrecarga upstream.

Task 4: Identify which endpoint is generating the broken pipes

cr0x@server:~$ sudo awk '$9==499 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  211 /download.bin
   63 /reports/export
   31 /api/v1/stream
   12 /favicon.ico

Significado: Descargas largas y exportaciones son imanes clásicos de abortos de cliente.
Decisión: Si se concentra en respuestas grandes, considera buffering, soporte de ranges, descargas reanudables y muestreo de logs para 499/EPIPE.

Task 5: Check upstream response time patterns (is the server slow?)

cr0x@server:~$ sudo awk '{print $(NF-1)}' /var/log/nginx/access.log | awk -F= '{print $2}' | sort -n | tail -n 5
12.991
13.105
13.442
14.003
15.877

Significado: Esto asume que registras algo como upstream_response_time=....
Las latencias en la cola alta significan que los clientes pueden expirar o rendirse, provocando EPIPE cuando finalmente escribes.
Decisión: Si las colas altas aparecen, pivota a comprobaciones de CPU, memoria e IO; también verifica que los timeouts del proxy no sean demasiado agresivos.

Task 6: Confirm system pressure (CPU, load, memory) around the event

cr0x@server:~$ uptime
 09:14:22 up 23 days,  4:11,  2 users,  load average: 18.91, 19.22, 17.80

Significado: Load average muy por encima del número de CPU (o de lo normal en este host) sugiere contención.
Decisión: Si la carga es alta, valida si es saturación de CPU, IO wait o backlog de runnable.

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        29Gi       420Mi       1.2Gi       1.6Gi       1.0Gi
Swap:          2.0Gi       1.8Gi       200Mi

Significado: Poca memoria disponible y swap intenso es cómo se llega a “todo va lento, los clientes se rinden, writes EPIPE”.
Decisión: Si hay swapping, trata el broken pipe como síntoma. Detén la fuga de memoria, añade memoria, reduce concurrencia o mejora la estrategia de caché.

Task 7: Check for OOM kills (the silent broken-pipe factory)

cr0x@server:~$ sudo journalctl -k -S -6h | grep -i -E "oom|killed process|out of memory" | tail -n 20
Dec 31 09:00:02 api-01 kernel: Out of memory: Killed process 8871 (app) total-vm:4123456kB, anon-rss:1987654kB, file-rss:0kB, shmem-rss:0kB

Significado: Si el kernel está matando tu app, los clientes verán desconexiones; los upstreams verán broken pipe al intentar escribir de vuelta.
Decisión: Deja de tratar EPIPE como una molestia de logging; corrige límites de memoria, fugas o fan-out de peticiones que causan picos.

Task 8: Inspect TCP resets and retransmits (network truth serum)

cr0x@server:~$ sudo nstat -az | egrep "TcpExtTCPSynRetrans|TcpRetransSegs|TcpOutRsts|TcpInRsts"
TcpExtTCPSynRetrans             18                 0.0
TcpRetransSegs                  4201               0.0
TcpOutRsts                      991                0.0
TcpInRsts                       874                0.0

Significado: Retransmisiones y RSTs en aumento pueden indicar pérdida de paquetes, sobrecarga, problemas de conntrack o enforcement de timeouts inactivos.
Decisión: Si RSTs/retransmit suben con EPIPE, captura tráfico y revisa timeouts de middlebox; también verifica errores en la NIC.

Task 9: Check NIC and kernel-level drops/errors

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 1234567      0   12451       0   12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109 2345678      0    9421       0       0

Significado: Las pérdidas a nivel de interfaz no siempre son fatales, pero se correlacionan fuertemente con retransmisiones y desconexiones “aleatorias”.
Decisión: Si las pérdidas aumentan, revisa tuning de qdisc/backlog, moderación de interrupciones, saturación de CPU del host o congestión de red upstream.

Task 10: See which connections are in which state (are you drowning in half-closed sockets?)

cr0x@server:~$ ss -s
Total: 2134
TCP:   1821 (estab 712, closed 943, orphaned 7, timewait 122, ports 0)
Transport Total     IP        IPv6
RAW       0         0         0
UDP       31        27        4
TCP       878       831       47
INET      909       858       51
FRAG      0         0         0

Significado: Muchos timewait puede ser normal para conexiones cortas, pero grandes oscilaciones pueden indicar problemas de keepalive o reutilización.
Decisión: Si estab es enorme y estable, puedes tener clientes lentos; si closed/orphaned sube, investiga terminaciones abruptas y crashes.

cr0x@server:~$ ss -tan state time-wait '( sport = :443 )' | head
State      Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT  0      0      10.0.1.10:443     198.51.100.25:51322
TIME-WAIT  0      0      10.0.1.10:443     203.0.113.77:44118

Significado: Confirma la distribución por puerto y estado.
Decisión: Si TIME-WAIT es excesivo y causa agotamiento de puertos en clientes o NAT, incrementa la reutilización vía diseño (keepalive) en lugar de hacks del kernel.

Task 11: Verify timeout mismatches (Nginx example)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep "keepalive_timeout|proxy_read_timeout|proxy_send_timeout|send_timeout" | head -n 20
keepalive_timeout 65;
send_timeout 30s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

Significado: Si send_timeout es menor que tu tiempo típico de respuesta para descargas grandes, verás broken pipes.
Si proxy_read_timeout es demasiado bajo, las solicitudes upstream se cortarán y el proxy puede resetear.
Decisión: Alinea timeouts a lo largo de la cadena (cliente ↔ LB ↔ proxy ↔ app). Incrementa timeouts solo cuando puedas asumir el pinning de recursos.

Task 12: Inspect systemd service limits and kill behavior

cr0x@server:~$ sudo systemctl show app.service -p TimeoutStopUSec -p KillSignal -p KillMode -p Restart -p RestartSec
TimeoutStopUSec=30s
KillSignal=SIGTERM
KillMode=control-group
Restart=on-failure
RestartSec=2s

Significado: Si tu app necesita 90 segundos para drenar, pero systemd le da 30, generarás desconexiones durante despliegues.
Decisión: Ajusta shutdown ordenado: incrementa TimeoutStopUSec, implementa endpoints de drenado y asegura que el proxy deje de enviar tráfico primero.

Task 13: Confirm who closed first with a short tcpdump

cr0x@server:~$ sudo tcpdump -i eth0 -nn -s 0 -c 50 'tcp port 443 and (tcp[tcpflags] & (tcp-fin|tcp-rst) != 0)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:13:02.112233 IP 203.0.113.10.51544 > 10.0.1.10.443: Flags [F.], seq 12345, ack 67890, win 64240, length 0
09:13:02.112450 IP 10.0.1.10.443 > 203.0.113.10.51544: Flags [R], seq 67890, win 0, length 0

Significado: Ves FIN del cliente y luego un reset del servidor (o viceversa). Esta es la verdad absoluta de quién colgó.
Decisión: Si los clientes envían FINs temprano, probablemente sean abortos/timeouts del lado cliente; si el servidor envía RSTs, busca cierres de app/proxy, crashes o timeouts agresivos.

Task 14: If storage is involved, check IO latency (slow disk makes clients bail)

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0 (api-01)  12/31/2025  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    5.20   18.30    0.00   54.40

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1         90.0   120.0  8200.0  5400.0     92.0     7.80   38.20   41.10   35.90   0.80  17.00

Significado: Alto await y %iowait pueden bloquear el manejo de peticiones. Los clientes hacen timeout, luego tus writes chocan con EPIPE.
Decisión: Si la latencia de disco sube con broken pipes, arregla la ruta de IO: optimiza consultas, cachea, usa almacenamiento más rápido o añade backpressure—no solo ajustes de timeouts.

Tres mini-historias corporativas desde las trincheras

1) Incidente causado por una suposición errónea: “Broken pipe siempre es aborto de cliente”

Una empresa SaaS mediana actualizó una flota Debian y notó más líneas “broken pipe” en sus logs API. El responsable on-call lo descartó:
“Eso son personas cerrando pestañas.” Era plausible; su tráfico era mayormente navegadores y las gráficas parecían bien—al principio.

Dos días después, una integración con un partner empezó a fallar. No eran navegadores. Eran máquinas. El job por lotes del partner abría una conexión, enviaba un payload
y esperaba una respuesta. Su job reintentaba al fallar, aumentando la concurrencia. Mientras tanto, el servidor API estaba lento porque un trabajo de compactación en background
saturaba el IO de disco. Las peticiones se encolaron. El partner alcanzó su timeout cliente y cerró sockets.

La API terminó escribiendo respuestas a conexiones que ya no existían. EPIPE inundó los logs. El error no era la enfermedad;
era un síntoma de latencia suficiente para disparar timeouts cliente. Cuando los reintentos aumentaron, la cola empeoró, y las gráficas
dejaron de estar bien. Estaban en llamas.

La solución no fue “suprimir logs de broken pipe.” La solución fue priorizar IO de primer plano, mover compactación fuera de pico, añadir rate limiting
y alinear timeouts cliente con los SLOs del servicio. Tras eso, los broken pipes bajaron a una línea base aburrida y baja—justo donde deben estar.

2) Optimización que salió mal: tuning agresivo de keepalive

En una gran empresa con más proxies que empleados (aproximadamente), alguien intentó “optimizar” el manejo de conexiones.
La idea: mantener conexiones abiertas más tiempo para reducir handshakes TLS y CPU. Subieron los timeouts de keepalive en el proxy inverso y la app.

El balanceador de carga delante no se enteró. Tenía un timeout de inactividad más corto. Así que el LB dejó caer silenciosamente conexiones inactivas, y el proxy
intentó reutilizarlas. De vez en cuando, una conexión reutilizada ya estaba muerta. El siguiente write disparaba un reset o un broken pipe,
dependiendo de quién lo notara primero.

Peor aún: el keepalive más largo implicó más sockets inactivos. El uso de descriptores de archivo subió. Durante picos de tráfico, el proxy alcanzó su límite de fd,
comenzó a fallar en accepts y los clientes reintentaron. Ahora tenías churn innecesario de reconexiones y agotamiento de recursos. Fue una lección magistral
de resolver el cuello de botella equivocado.

La solución final fue aburrida y correcta: alinear timeouts de inactividad LB ↔ proxy ↔ app, limitar solicitudes keepalive y establecer límites de fd sensatos.
La CPU subió un poco. La tasa de incidentes bajó mucho. Es un intercambio que merece la pena.

3) Práctica aburrida pero correcta que salvó el día: shutdown ordenado y disciplina de drenado

Una plataforma cercana a finanzas corría una pila basada en Debian detrás de una capa de proxy. Tenían cultura de “no heroísmos”: cada servicio tenía
comportamiento de shutdown documentado y un proceso de drenado aplicado. Sonaba burocrático hasta que dejó de serlo.

Una tarde, una actualización de kernel requirió reboots. Los reboots son donde los errores “broken pipe” aman reproducirse: conexiones se rompen a mitad de vuelo,
los clientes reintentan, los upstreams se tambalean. Pero esta vez, el equipo siguió su checklist. Los nodos se cordonearon (o se sacaron de rotación),
el tráfico se drenó, las peticiones largas terminaron y solo entonces se detuvieron los servicios.

En los logs, “broken pipe” apenas apareció. Más importante: las tasas de error visibles para clientes se mantuvieron planas. El equipo pudo irse a casa a su hora.
El único drama fue alguien que protestó que el proceso era “muy lento”, frase típica que se dice justo antes de que la ruta rápida les cueste el fin de semana.

La lección: drenar conexiones y respetar ventanas de shutdown ordenadas previene una cantidad sorprendente de ruido EPIPE y dolor real para usuarios.
No es glamuroso. Funciona.

Broma #2: El “deploy rápido” que ignora el drenado es como hacer speedrun en una fábrica de porcelana—técnicamente impresionante, financieramente confuso.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Nginx registra “writev() failed (32: Broken pipe) while sending to client”

Causa raíz: Cliente desconectado a mitad de respuesta (pestaña cerrada, cambio de red móvil, SDK impaciente).
A veces desencadenado por respuestas lentas del servidor.

Solución: Si es baseline normal, reduce nivel de logs/muestreo para esta clase; si hay un pico que se correlaciona con latencia, arregla la lentitud primero.

2) Síntoma: La app registra EPIPE al escribir a upstream (Redis/BD/HTTP interno)

Causa raíz: El upstream cerró la conexión por timeout inactivo, sobrecarga, máximo de clientes o reinicio; o tu cliente reutilizó una conexión obsoleta.

Solución: Alinea keepalive y timers inactivos, implementa reintentos con jitter (con cuidado) y confirma métricas de saturación del upstream.

3) Síntoma: Picos de broken pipe exactamente durante despliegues

Causa raíz: No hay shutdown ordenado, ventana de terminación demasiado corta, readiness cambia demasiado tarde, proxy sigue enroutando a instancias en drenado.

Solución: Añade fase de drenado: quita de rotación, evita aceptar nuevo trabajo, termina trabajo en vuelo y luego para. Ajusta timeouts de systemd.

4) Síntoma: Broken pipe + timeouts 504 gateway

Causa raíz: Upstream demasiado lento o bloqueado (CPU, IO, contención de locks), timeout de proxy muy corto o encolamiento.

Solución: Aumenta timeout solo tras validar headroom de recursos. Mejor arreglar latencia: reducir trabajo, cachear, optimizar consultas, añadir capacidad.

5) Síntoma: Broken pipe aparece después de habilitar streaming de respuesta HTTP

Causa raíz: El streaming hace visibles los abortos de cliente; además los proxies pueden bufferizar inesperadamente o caducar streams inactivos.

Solución: Configura el streaming intencionalmente: desactiva buffering donde haga falta, envía bytes de keepalive periódicos si procede, ajusta timeouts del proxy.

6) Síntoma: Comando de shell imprime “Broken pipe” en un pipeline

Causa raíz: El comando downstream sale temprano (p. ej. head), el upstream sigue escribiendo y recibe SIGPIPE/EPIPE.

Solución: Normalmente ignóralo. Si rompe scripts, redirige stderr o usa herramientas que detengan el upstream limpiamente (o manejen SIGPIPE).

7) Síntoma: Muchos broken pipes después de cambiar keepalive

Causa raíz: Desajuste de timeouts entre capas; reutilización de conexiones muertas; LB con timeout de inactividad más corto que proxy/app.

Solución: Documenta y alinea timeouts de inactividad end-to-end; verifica con captura de paquetes; despliega cambios de forma gradual.

8) Síntoma: Broken pipe junto a OOM kills o tormentas de reinicio

Causa raíz: El proceso muere mientras atiende solicitudes; los pares siguen escribiendo a sockets muertos.

Solución: Arregla límites/fugas de memoria, reduce concurrencia, establece backoff de reinicio sensato e implementa hooks de terminación ordenada.

Listas de verificación / plan paso a paso

Checklist A: Decide si es ruido o un incendio

1. ¿Dónde se registra? Logs de proxy edge vs. logs de servicio interno vs. scripts batch.
2. ¿La tasa cambia? Una baseline estable suele ser ruido; una tendencia al alza es una advertencia.
3. ¿Hay síntomas emparejados? 5xx, 504, crecimiento de colas, CPU steal, swap, latencia de IO, retransmisiones.
4. ¿Está concentrado? Un endpoint, un upstream, un nodo, una AZ: investiga esa porción.
5. ¿Se alinea con deploy/restart? Si sí, arregla drenado y comportamiento de shutdown primero.

Checklist B: Ajusta timeouts y keepalive con seguridad

1. Inventaria timeouts en cada salto: cliente, LB, proxy inverso, servidor de app, clientes de dependencia.
2. Escoge un objetivo: el upstream debería expirar después del downstream, no antes (generalmente), y el LB no debe ser el más corto salvo intención.
3. Los keepalive idle deben ser consistentes; si no, espera reutilización de conexiones obsoletas.
4. Despliega cambios a un subconjunto pequeño; vigila resets/retransmisiones y la tasa de EPIPE.
5. Documenta el “contrato” para que la próxima optimización bienintencionada no lo rompa otra vez.

Checklist C: Hace que los despliegues dejen de causar broken pipes

1. Asegura que la instancia deje de recibir tráfico antes de parar el proceso.
2. Implementa readiness que cambie temprano (dejar de anunciar ready) y liveness que evite flapping.
3. Confirma que systemd (u orquestador) da una gracia de terminación suficiente para las peticiones en vuelo en el peor caso.
4. Registra fases de apagado: “draining started”, “no longer accepting”, “in-flight=…”, “shutdown complete”.
5. Prueba desplegando bajo carga y mide errores visibles por cliente, no solo líneas en logs.

Checklist D: Reduce el ruido de broken-pipe sin cegarte

1. Etiqueta logs con contexto (endpoint, upstream, bytes enviados, tiempo de request).
2. Muestra muestreo de errores EPIPE repetitivos; conserva fidelidad completa para 5xx y timeouts.
3. Mantén un contador métrico para EPIPE por componente; alerta por tasa de cambio, no por existencia.
4. Conserva una pequeña muestra de logs sin muestrear para análisis forense.

Preguntas frecuentes

1) ¿Es “broken pipe” un bug de Debian 13?

Casi nunca. Es un error estándar de UNIX/Linux expuesto por las aplicaciones. Debian 13 puede cambiar versiones y defaults, lo que cambia la visibilidad, no la física.

2) ¿Por qué veo “BrokenPipeError: [Errno 32]” en Python?

Python lanza BrokenPipeError cuando un write encuentra EPIPE. Normalmente significa que el par cerró el socket (cliente abortó, timeout upstream o un proxy lo cortó).

3) ¿Por qué ocurre más con Nginx o proxies inversos?

Los proxies están en el medio. Escriben a clientes y upstreams constantemente y son los primeros en descubrir que un par desapareció.
Además registran estas condiciones más explícitamente que muchas apps.

4) ¿Debo deshabilitar SIGPIPE?

Muchos servidores de red ignoran SIGPIPE para que una desconexión de cliente no mate el proceso. Está bien.
No lo “deshabilites” a ciegas en herramientas aleatorias; entiende si quieres un crash (fail fast) o un retorno de error (manejarlo).

5) ¿Significa “broken pipe” corrupción de datos?

No por sí solo. Significa que un write no llegó a un lector. Si estás streameando una respuesta, el cliente recibió una respuesta parcial.
Para uploads o RPC internos, necesitas idempotencia y reintentos para evitar estado parcial.

6) ¿Por qué lo veo en pipelines de shell cuando uso head?

Porque head sale tras obtener suficientes líneas. El proceso upstream sigue escribiendo y choca con una tubería cerrada.
Es normal; redirige stderr si te molesta en scripts.

7) ¿Cómo digo si cerró primero el cliente o el servidor?

Usa una captura de paquetes breve (dirección FIN/RST) o correlaciona logs: códigos de aborto cliente (como 499) vs timeouts upstream (504) vs reinicios de servicio.
En duda, tcpdump durante 60 segundos es mejor que discutir.

8) ¿Debería simplemente subir todos los timeouts para pararlo?

No. Subir timeouts puede ocultar sobrecarga e incrementar el pinning de recursos (más requests atascados concurrentes, más memoria, más sockets).
Arregla la latencia o alinea timeouts con intención; no solo “gira las perillas hacia la derecha”.

9) ¿Por qué pica durante backups o grandes exportaciones?

Las respuestas de larga duración amplifican la impaciencia y la variabilidad de red. IO lento (disco, object store, BD) aumenta tiempos de respuesta, los clientes hacen timeout y luego los writes impactan EPIPE.

10) ¿Es seguro filtrar “broken pipe” de los logs?

A veces. Si has demostrado que son mayormente abortos de cliente y tienes métricas para cambios de tasa, el muestreo o filtrado puede reducir ruido.
No lo filtres si está ligado a timeouts upstream, llamadas internas o eventos de despliegue.

Conclusión: siguientes pasos para reducir ruido y riesgo

“Broken pipe” en Debian 13 no es ni una crisis ni un encogimiento de hombros. Es una pista de que un lado de una conversación se fue temprano.
Tu trabajo es decidir si esa salida temprana fue comportamiento normal, un desajuste de timeouts o un sistema bajo estrés.

Pasos prácticos que rinden:

1. Clasifica por origen: proxy edge vs app vs dependencias internas.
2. Correlaciona con timeouts y saturación: si la latencia o la presión de recursos sube, persigue eso primero.
3. Alinea timeouts end-to-end: cliente ↔ LB ↔ proxy ↔ app, y documenta el contrato.
4. Arregla el drenado en despliegues: el shutdown ordenado es más barato que forensear logs.
5. Domina el ruido sin cegarte: muestrea logs EPIPE repetitivos, pero alerta por cambios de tasa y por síntomas emparejados (504/5xx/reinicios).

La meta no es eliminar cada línea “broken pipe”. La meta es asegurarse de que las que queden sean aburridas, entendidas y no el primer capítulo del caso #76.