El nodo se colgó y el registro no guardaba nada de los últimos 12 días: la culpa era log2ram

Un nodo Proxmox se colgó de madrugada. Lo reinicié y fui a mirar el registro para ver qué había pasado antes del cuelgue. Y me encontré con esto: no había nada de los últimos doce días. Del arranque de ese día se saltaba directamente a dos semanas antes.

Quién tenía /var/log en memoria

Ese nodo tenía instalado log2ram, que venía con una herramienta de gestión para Proxmox. log2ram monta /var/log en memoria RAM para ahorrar escrituras al disco, y cada cierto tiempo (cada pocas horas y por la noche) copia lo que hay en RAM al disco de verdad.

La idea es buena para una tarjeta SD de una Raspberry. En un servidor con discos normales aporta poco, y en este caso hacía mucho daño.

Cómo acababa borrando lo más nuevo

La cadena fue esta:

1. Con la opción de respetar a journald activada, log2ram no copiaba nunca el fichero activo del registro (system.journal).
2. En el disco quedaba uno muy antiguo, de meses atrás, que volvía a la RAM en cada arranque como si fuera el actual.
3. Eso desordenó la numeración interna del registro: ficheros viejos con números más altos que los nuevos.
4. Cuando el registro llegaba a su tamaño máximo, journald borraba «lo más antiguo» según esa numeración… que en realidad era lo más reciente.

Resultado: el registro conservaba julio y agosto, y tiraba lo de la última semana y media. Justo lo que necesitaba para entender el cuelgue.

El arreglo

En un servidor con discos normales no merece la pena, así que lo desactivé (sin desinstalarlo, por si la herramienta lo vuelve a esperar):

systemctl disable --now log2ram log2ram-daily.timer

Después aparté los ficheros viejos del registro a otra carpeta (siguen siendo legibles con journalctl --file), reinicié journald y comprobé que /var/log ya era disco y que el registro salía en orden.

Lo hice en todos los nodos, porque la herramienta lo había instalado en todos. Y como podría volver a activarlo al actualizarse, tengo una comprobación que mira cada hora si /var/log vuelve a estar en memoria.

Lo que me llevé de esto

• Antes de que haga falta, comprueba que el registro de tus servidores sobrevive a un reinicio y está completo: journalctl --list-boots te lo dice en un momento.
• findmnt /var/log: si sale tmpfs, tu registro vive en RAM y se pierde con un cuelgue.
• Las herramientas «todo en uno» instalan cosas por su cuenta. Revisa qué han tocado.
• log2ram tiene sentido en tarjetas SD; en un servidor con SSD o discos normales, el desgaste que ahorra no compensa.