Primer diagnóstico de un proceso que falla con strace y tcpdump

Objetivo

Responder en pocos minutos y sin modificar código dos preguntas sobre un proceso que se cuelga o falla: ¿qué está esperando? y ¿responde el otro extremo de la red?

Requisitos previos

Root, o bien CAP_SYS_PTRACE para strace y CAP_NET_RAW para tcpdump. El módulo Yama del kernel (kernel.yama.ptrace_scope, documentado en la página citada) restringe la conexión a procesos ajenos cuando vale 1 o más, de modo que un attach sin privilegios puede fallar incluso con un proceso propio. Conviene tener una idea aproximada del ID del proceso y del puerto implicado.

Pasos

1. Obtén el PID y el estado actual del proceso: ps -o pid,stat,wchan:32,cmd -p PID. Un estado D o un wchan que nombre una función de red ya acota la búsqueda.
2. Conéctate brevemente: timeout 20 strace -f -p PID -T -e trace=%network,%file -o /tmp/trace.txt (-f / --follow-forks sigue hilos y procesos hijos, -T muestra el tiempo empleado en cada llamada, %network y %file seleccionan grupos de llamadas). Un proceso bloqueado en read, recvfrom o futex durante toda la ventana está esperando, no trabajando.
3. Lee en el archivo las últimas llamadas completadas antes del bloqueo: qué descriptor, qué dirección (connect muestra el otro extremo) y qué ruta. Asocia los descriptores con ls -l /proc/PID/fd.
4. Captura el tráfico correspondiente con un filtro estrecho y un límite: tcpdump -ni any -c 200 -w /tmp/cap.pcap 'host 203.0.113.5 and port 5432'. -n evita las consultas DNS, -c detiene la captura tras 200 paquetes y -w escribe los paquetes en bruto (el snaplen por defecto de 262144 bytes conserva los paquetes completos).
5. Inspecciona con tcpdump -nr /tmp/cap.pcap o con un analizador gráfico. Busca SYN repetidos sin SYN-ACK (nadie escucha o hay filtrado), retransmisiones (pérdida de paquetes), RST (el otro extremo rechazó o reinició la conexión) o una petición sin respuesta dentro del timeout de la aplicación.
6. Detén ambas herramientas, anota la conclusión y solo entonces plantéate herramientas más profundas (perf, profilers de aplicación, capturas más largas con -C y -W para rotar archivos).

Resultado esperado

Un diagnóstico de una línea del tipo "bloqueado en recvfrom en la conexión con X; X nunca envía respuesta" o "la petición nunca sale del host", que indica cuál es el siguiente componente que hay que examinar.

Límites y base de verificación

strace(1) indica que un proceso trazado se ejecuta más lentamente que uno sin trazar; no lo dejes conectado a una ruta crítica de producción. La mitigación del manual, --seccomp-bpf, solo funciona cuando strace lanza el propio comando con -f; no es aplicable a un proceso al que strace se conecta con -p, por lo que la ventana de conexión y desconexión descrita arriba es el único límite. Las capturas contienen payloads y secretos: trata los archivos pcap como sensibles y bórralos. En el tráfico TLS solo se ven el handshake y los tamaños. Las opciones de las herramientas proceden de los manuales citados; no se afirman cifras de tiempo ni de sobrecarga.