Llegué a la oficina y, al revisar los mails que me envían los servidores, descubrí que faltaban los correos de uno de mis servidores OpenBSD. Revisando el log del sistema, las tareas programadas se ejecutaron normalmente pero hubo un problema con el envío de correo.



Al intentar enviar un correo desde línea de comandos, utilizando mail, el error era el siguiente:

send-mail: command failed: 421 4.3.0: Temporary Error

Falló el comando (del protocolo SMTP) con un error temporal. ¿Error temporal? Veamos qué dice el log:

# less /var/log/maillog
Oct 24 08:15:33 obsd smtpd[99616]: cd3f411ef6a9b441 smtp event=connected address=local host=obsd.linuxito.com
Oct 24 08:15:33 obsd smtpd[63791]: warn: not enough disk space: 4% left
Oct 24 08:15:33 obsd smtpd[63791]: warn: temporarily rejecting messages
Oct 24 08:15:33 obsd smtpd[99616]: cd3f411ef6a9b441 smtp event=failed-command address=local host=obsd.linuxito.com command="MAIL FROM:<root@obsd.linuxito.com>  " result="421 4.3.0: Temporary Error"
Oct 24 08:15:33 obsd smtpd[99616]: cd3f411ef6a9b441 smtp event=closed address=local host=obsd.linuxito.com reason=quit

El primer evento registra la conexión local desde el cliente mail, lo que inmediatamente dispara la advertencia:

warn: not enough disk space: 4% left

Seguida de:

warn: temporarily rejecting messages

Simplemente genial. El servidor de correo local (smtpd) se da cuenta que queda poco espacio en disco (apenas un 4% de espacio disponible) y decide no aceptar correo entrante hasta que se solucione la situación, y así no terminar de ocupar el 100% de espacio en disco y colapsar el servidor. Por este tipo de implementaciones OpenBSD es un sistema tan robusto, más allá de todo lo estrictamente relacionado con la seguridad.

En sistemas GNU/Linux en cambio, me ha pasado varias veces que el disco simplemente se llena y los servicios se caen. Con lo cual se debe hacer una limpieza y reinicio de todos los servicios afectados.

En este servidor OpenBSD simplemente recuperé un poco de espacio en disco y el servicio de correo volvió a la normalidad sin tener que hacer nada más. No fue necesario indicarle al demonio (a través de una señal ni nada por el estilo) que ya podía seguir trabajando normalmente. Sólo borrar algunos archivos para hacer espacio y siguió trabajando como si nada hubiese pasado.

Lógicamente todos los mensajes enviados en este período se perdieron ya que fueron rechazados por el servidor. En el caso de scripts y tareas programdas, estos eventos quedan registrados en logs o simplemente se pierden. Pero en los clientes de correo típicos, los mensajes quedan encolados en bandeja de salida hasta que el servidor los acepte. Gracias a esto la disrupción del servicio es casi inexistente.


Tal vez pueda interesarte


Compartí este artículo