Problema con sockets en máquina con SUSE

[Enrique Gómez]

Buenas noches,

Creo que mi pregunta va a ser difícil de contestar, pero bueno, veamos qué se cuece.

La situación es que tenemo una máquina en producción (a partir de ahora A) que generan bastantes logs diarios. Mediante un programita que nos hemos montado, enviamos a través de red estos logs en real time a una máquina (a partir de ahora B) que tenemos para parsear logs, generar alarmas... etc...

El caso, es que entre las máquinas A y B en teoría sólo debería de haber una conexión TCP ESTABLISHED continuamente. Sin embargo, en la máquina B, ahora existen cerca de 400 conexiones ESTABLISHED con A, y sin embargo A dice que sólo tiene 1 conexión ESTABLISHED con B. ¿Divertido eh?

esnifando tráfico efectivamente A dice la realidad, porque en el resto de conexiones ESTABLISHED de B no se ve ni un sólo paquete.

¿Sobran unas cuantas verdad? xD Estas máquinas están separadas en distintas sedes, entre Firewalls, F5... y demás arquitectura que seguramente desconozca.

He probado a utilizar tcpkill (Por cierto, una gran utilidad para otros casos) para cepillarme las conexiones que sé que sobran, pero no sirve, porque utiliza un paquete RST para cerrar la conexión, y este paquete para generarse necesita que al menos haya algún intercambio de paquetes (Inexistente).

en /proc/[PID]/fd/ de la máquina B están los 400 sockets "abiertos"... he probado un rm a ver si colaba, pero nada...xD.

El problema es que cada hora en A se reinician las conexiones (Para garantizar que no se queda fastidiado el proceso de A) y se van generando cada hora nuevas conexiones en B. Sin embargo parece que B no se entera de que se cierran y las deja ESTABLISHED.

¿Sabéis alguna manera de cerrar los sockets que se han quedado inútilmente abiertos?

Gracias a todos ;)

Salu2

[Francisco J.]

¿y por que no enviais los log directamente a la otra máquina?
Sin el programa ese que os habeis montado.

Haz una prueba para comprobar que no se pierden paquetes o los fragmente mucho

[_TuXeD_]

Si es por tema seguridad puedes pasar el trafico de syslog por un tunel ssl o ssh

[Manolo]

Parece que todo apunta que no se estan cerrando correctamente las conexiones ;) (evidente)

Podias mandar un poco mas de info.
SO. de las maquinas A y B
Un trozo o todo el codigo de la aplicaicion que envia los logs.
¿Como establece las conexiones?
¿Como las cierra?.....

Con tan poca info podemos ver mas bien poco

[Enrique Gómez]

Buenas, los logs los tenemos que enviar en vivo para poder generar estadísticas en tiempo real. Siento no haberos contestado antes, pero ya sabéis que a veces esta profesión no permite demasiado margen de tiempo libre.

Os agradezco los comentarios, pero finalmente logré minimizar el problema bastante, os lo voy a intentar explicar. En la máquina B, donde se reciben los logs, está instalada la aplicación spread, no sé si la conocéis, pero es bastante interesante.

Con esta aplicación podemos tener una máquina servidora de la aplicación, y máquinas clientes. Estos clientes pueden enviar/recibir datos, según estén configurados. Si la máquina servidora no tiene ningún cliente receptor los datos que se envíen por los clientes simplemente se obvian, no se almacenan en ningún sitio.

Bien, pues en nuestro entorno anterior, las máquinas que envían los logs (A), tiene instalada la versión de este cliente en modo envío. La máquina que recibe los logs (B) tiene montado el servidor y además un cliente en modo recepción, de modo que este cliente guarda en disco todo lo que envíen los clientes en modo de envío.

Se ha elegido este SW porque es fácil integrar clientes al sistema, y así poder concentrar todos los logs de varias máquinas en una.

El problema del que os hablé lo conseguí solucionar eliminando uno de los clientes receptores que tenía instalado en la máquina B. Sí, tenía 2, uno le utilizaba para guardar los logs en disco, y el otro procesaba la información y generaba estadísticas en vivo. Al unificarlos, conseguí evitar el problema con el que inicié este hilo... y bueno, la verdad es que de momento no le he encontrado una explicación clara de porqué eliminando un proceso de la máquina B, ya no se quedan "atontadas" las conexiones entre A y B.

En cualquier caso, gracias por vuestro interés. Si tenéis alguna hipótesis de porqué ha podido pasar esto será bienvenida! Y por supuesto os invito a que conozcáis spread si es que aún no lo conocéis.

Saludos