Cuando el correo deja de llegar: análisis de una caída en una plataforma de correo Zimbra-PMGpmg-zimbra.png

Por cuestiones de confidencialidad no puedo compartir capturas ni publicar comandos ejecutados junto con sus resultados. Aun así, vale la pena contar el análisis del caso porque terminó siendo una situación bastante particular y probablemente despierte curiosidad en quienes trabajan administrando este tipo de plataformas.

Durante el día comenzaron a llegar las primeras alertas desde usuarios finales: los correos electrónicos no estaban llegando a destino.

En un primer momento no existían señales de una caída del servicio. La plataforma continuaba respondiendo, no se observaban errores evidentes y, a simple vista, el entorno seguía operativo.

Pero como suele pasar en incidentes de este tipo, el síntoma visible (“no llegan correos”) era solo la superficie de un problema más profundo.

Así comenzó el proceso de diagnóstico sobre una plataforma de correo legacy compuesta por Zimbra y PMG, que actualmente continúa en operación mientras avanza una migración tecnológica planificada hacia Carbonio y PMG.

Paso 1 — Verificar el estado de los servicios

El primer paso fue revisar el estado de los servicios involucrados.

Rápidamente apareció algo que llamó la atención: el servicio PMG (pmg-smtp-filter) registraba múltiples fallas de conexión hacia la base de datos, acompañadas por errores repetidos asociados al runtime de Perl (segfault).

Lo curioso era que estos eventos no comenzaron con el incidente, sino que venían ocurriendo desde varias horas antes de la caída.

Con ese dato se pasó a verificar el estado del servicio de base de datos… y efectivamente no se estaba ejecutando.

No era una señal especialmente tranquilizadora.

Se intentó iniciar nuevamente el servicio esperando encontrar errores adicionales durante el arranque; por suerte la base levantó correctamente y sin fallos visibles.

Con el servicio operativo nuevamente, el foco dejó de estar en restaurar disponibilidad y pasó a entender por qué la base de datos se había detenido.

Esto era especialmente relevante porque PMG consulta continuamente reglas y políticas sobre los correos que atraviesan el sistema.

El siguiente paso fue entonces revisar el histórico de eventos alrededor del momento del incidente.

Paso 2 — Buscar eventos alrededor del horario del incidente

Al revisar los logs apareció algo interesante.

Múltiples conexiones activas estaban siendo cerradas por el propio motor:

terminating connection because of crash of another server process
possibly corrupted shared memory

Ese mensaje normalmente indica que:

  • un proceso interno terminó de forma anormal;

  • el proceso principal decidió detener el resto para proteger consistencia;

  • el motor entra en recuperación.

Un poco antes aparecía la pieza clave:

server process was terminated by signal 11: Segmentation fault

Un SIGSEGV (Segmentation Fault).

Ese dato cambió completamente el enfoque.

Ya no estábamos buscando un problema funcional del correo.

Estábamos frente a un crash de proceso.

Paso 3 — Validar hipótesis clásicas

Antes de asumir un bug de aplicación se revisaron las causas habituales:

Disco

Se verificaron errores de filesystem y eventos del kernel.

Resultado:

sin errores detectados

Memoria

Se buscaron eventos relacionados con:

OOM
Killed process
memory

Resultado:

sin evidencia de agotamiento de memoria

Host de virtualización

También se revisaron eventos del host físico buscando:

  • errores ECC;

  • reinicios;

  • eventos de virtualización;

  • fallas de almacenamiento.

Resultado:

sin correlación con el horario del incidente

Hasta ese punto no había señales de infraestructura.

Paso 4 — Encontrar el verdadero patrón

Al seguir profundizando apareció algo más importante.

El componente encargado del procesamiento SMTP venía registrando fallos repetidos.

Los mensajes se repetían durante horas:

segfault
signal 11

Y entre esos eventos aparecían errores de conexión hacia la base de datos.

La secuencia terminó siendo algo parecido a esto:

Procesamiento SMTP
        ↓
Error interno
        ↓
Segmentation fault
        ↓
Conexiones hacia BD fallan
        ↓
Motor entra en recuperación
        ↓
Usuarios dejan de recibir correos

Eso explicaba por qué el incidente parecía intermitente y no una caída total.

Paso 5 — Recuperación y validación

Una vez recuperado el servicio se ejecutaron tareas de mantenimiento sobre la base:

Reconstrucción de índices

REINDEX DATABASE

Objetivo:

  • reconstruir índices;

  • eliminar posibles inconsistencias lógicas.

Limpieza y actualización de estadísticas

VACUUM ANALYZE

Objetivo:

  • limpiar registros obsoletos;

  • actualizar estadísticas del optimizador.

Después de eso:

  • el sistema completó recuperación automática;

  • el flujo de correo volvió a normalidad;

  • no se observaron pérdidas de información.

Lecciones aprendidas

Este incidente dejó varias conclusiones útiles:

1. “Servicio activo” no significa “servicio sano”

El monitoreo mostraba procesos levantados.

Los logs mostraban otra historia.

2. Los síntomas rara vez están donde ocurre el problema

El usuario veía:

no llegan correos

La causa real estaba varios componentes más abajo.

3. Las plataformas legacy requieren observabilidad extra

En sistemas con muchos años de operación es común encontrar:

  • procesos que se recuperan solos;

  • errores silenciosos;

  • componentes que fallan en cascada.

Próximos pasos

Este incidente reforzó una decisión que ya estaba en planificación:

  • migración gradual de la plataforma de correo hacia Carbonio;

  • actualización del gateway de correo hacia una plataforma más reciente.

A veces el mejor resultado de un incidente no es restaurar el servicio.

Es entender por qué falló antes de que vuelva a pasar.

¡Salud y buen blogging!
— Valerka (Montevideo, Uruguay)
¿Te gustó el post? ¿Tenés dudas, comentarios o querés compartir tu experiencia?
Escribime a: valerkasystem@protonmail.com — ¡Siempre leo los mails y trato de responder cuando puedo!