Estoy ejecutando Netcat en un servidor Ubuntu 18.04.3 LTS, para escuchar en el puerto 469. Este servidor recibe solicitudes TCP frecuentes de otras máquinas al puerto 469, que uso para monitorear el tiempo de actividad del servidor. Empiezo Netcat con:
nc -kl 469
y puedo ver que el proceso está en vivo con:
$ ps -aux | grep 469que produce esta salida:
raíz 11041 0,0 0,1 13596 1060? S 31 Ago 0:21 nc -kl 469`
Este sistema funciona bien durante aproximadamente 24 a 28 horas, pero luego Netcat deja de responder. Después de investigar, creo que el problema es que el búfer Recv-Q "se llena". Normalmente, el búfer Recv-Q es cero hasta el punto en que Netcat deja de responder. Una vez que ha dejado de responder, el búfer Recv-Q es un 2 constante (en lugar del 0 normal). Puedo comprobar esto con "ss" de la siguiente manera.
$ ss -tnly luego veo esto, donde es visible el Recv-Q anormal de 2.
$ ss -tnl
Estado Recv-Q Enviar-Q Dirección local: Puerto Dirección del par: Puerto
ESCUCHAR 0 128 0.0.0.0:22 0.0.0.0:*
ESCUCHAR 0 64 0.0.0.0:42587 0.0.0.0:*
ESCUCHAR 0 128 0.0. 0.0:46663 0.0.0.0:*
ESCUCHAR 0 128 0.0.0.0:111 0.0.0.0:*
ESCUCHA 2 1 0.0.0.0:469 0.0.0.0:*
ESCUCHAR 0 128 127.0.0.53%lo:53 0.0.0.0:*
ESCUCHAR 0 128 [::]:22 [::]:*
ESCUCHAR 0 64 [::]:44057 [::]:*
ESCUCHAR 0 128 [ ::]:55085 [::]:*
ESCUCHAR 0 128 [::]:111 [::]:*
Tenemos varios otros servidores Ubuntu, que también ejecutan Netcat escuchando en el puerto 469, exactamente de la misma manera. NO fallan: llevan semanas funcionando. Pero este servidor falla una y otra vez, incluso después de reiniciarlo, y siempre después de más de 24 horas. La única diferencia entre este y los otros servidores (que se me ocurre) es que este servidor también tiene un volumen nfs montado (como se puede ver en el puerto de escucha 111 anterior).
¿Qué podría ser lo que causa esto? ¿Puedo borrar el Recv-Q de alguna manera (desde bash), para poder borrarlo con un intervalo regular (como solución temporal)? Cualquier ayuda es muy apreciada.
Respuesta1
Ahora encontré la respuesta a esta pregunta y quería publicarla aquí, en caso de que pueda ayudar a alguien más.
El problema era que el servidor también tenía instalado Strongswan y que las solicitudes TCP entrantes al puerto 469 procedían de una conexión IPSec de otro servidor. Lo que sucedió fue que la conexión IPSEC a veces se interrumpía por un tiempo muy corto cuando la conexión IPSec se reintroducía (aproximadamente cada 24 horas). Si eso sucediera justo en medio de una sincronización/ack de TCP en curso al puerto 469, lo dejaría en el limbo. Y entonces el "nc -kl" se atascaría, con paquetes en el búfer Recv-Q.
La solución fue configurar Strongswan para que la nueva clave se realizara sin interrupción. El aprendizaje fue que en lugar de buscar un problema con el búfer Recv-Q o Netcat, era necesario comprender la causa raíz, que en este caso fue comprender por qué TCP Syn/Ack no se pudo completar.