De vez en cuando esta bien reconocer tus propios errores (en mi caso los muchos errores) y este es el caso de esta entrada.

Feliz ante la idea de enviar información correos de control de forma simple (bueno, en mi descargo, en un sistema bastante ad hoc), me dio por “programar” un proceso utilizando GNU netcat, mediante una (muy corta) sesión SMTP que sabia que no podia fallar: algo así como:

#....
netcat servidordecorreo smtp << EEOOFF
RCPT TO: admin@servidor.es 
DATA 
Subject: $asunto 
$lineamensaje 
.$CRLF 
EEOOFF 
#.... 

Mas o menos, para que os hagais una idea…

Bueno el caso es que fue tan rápido y tan bien, que ese trozo de código chapucero quedo en la distribución (beta, afortunadamente) de un cliente.

Bien, bastantes dias despues de su distribución, me encuentro esta mañana con que ese equipo no ha ejecutado parte de los scripts de mantenimiento.

Cuando me conecto veo que dentro de la serie de procesos, el nc se ha quedado bloqueado, e indagando un poco mas veo que tiene un socket abierto en estado FIN_WAIT2, (¡Desde hace 5 dias!), bloqueando el resto de la cadena de scripts :-(.

Bien, lo que ocurrió fue que la conectividad de ese equipo se fue en el momento menos oportuno, y el nc se quedo eternamente esperando a que el servidor.es cerrara la conexión :-(. (una cosa que me gustaria saber, es porque FIN_WAIT2(al menos en linux 2.6) no tiene timeout, ¿alguna idea por ahi?).

Evidentemente fue mi error, un error bastante estupido por utilizar incorrectamente una herramienta que me lo ponia todo fácil (hasta que falla, claro).

La moraleja, a la baja mar todo sale.