Ahorra espacio en Linux: cómo configurar journald

Quien administra servidores o estaciones de trabajo en Linux ya ha pasado por la incómoda sorpresa de recibir un alerta de partición raíz llena sin haber instalado ningún paquete nuevo. En distribuciones modernas como Debian 13.7 y Ubuntu 26.04.1, uno de los principales villanos silenciosos detrás de este consumo exagerado de almacenamiento es el recolector de logs nativo de systemd. Saber cómo configurar journald es una habilidad fundamental para cualquier desarrollador o administrador de sistemas que desee mantener el sistema estable, predecible y libre del agotamiento repentino de espacio en disco.

systemd-journald es un servicio del sistema responsable de capturar mensajes de stdout, stderr, syslog y del kernel de todos los procesos gestionados por systemd. Centraliza la información de diagnóstico en archivos binarios indexados, lo que hace que las búsquedas sean extremadamente rápidas cuando se utiliza la utilidad journalctl. Sin embargo, la configuración predeterminada out-of-the-box de muchas distribuciones permite que journald ocupe hasta un 10% del tamaño total del sistema de archivos o hasta 4 GB de almacenamiento de forma persistente. En un servidor web o en un entorno de desarrollo que ejecute contenedores y microservicios de alto tráfico, este límite predeterminado se puede alcanzar en pocas semanas, consumiendo decenas de gigabytes que podrían aprovecharse para bases de datos y aplicaciones.

¿Por qué /var/log/journal crece sin parar?

El crecimiento descontrolado de la carpeta /var/log/journal ocurre debido a la forma en que systemd-journald maneja el ciclo de vida de los archivos de log. Por defecto, el servicio crea archivos de log estructurados y binarios organizados bajo un directorio nombrado con el identificador único del equipo (Machine ID). A diferencia de los archivos de texto plano tradicionales gestionados por la antigua utilidad logrotate, los logs de journald mantienen índices internos que garantizan una búsqueda rápida por metadatos, como UID, PID y unidad de systemd.

Cuando un servicio genera logs continuamente, el archivo de log activo alcanza un tamaño predeterminado, se cierra y se rota al estado de archivo archivado (archived). Si no se define ninguna regla explícita de cuota, journald continuará creando nuevos archivos hasta alcanzar el límite global calculado en función de la capacidad de la partición. En servidores de producción con discos NVMe de 500 GB o 1 TB, una cuota del 10% puede resultar en 50 GB a 100 GB de datos históricos guardados sin una necesidad real.

Además, los servicios con fallos en bucle (crash loops), aplicaciones en Python que registran stack traces extensas cada segundo, o depuradores activados en entornos de prueba aceleran exponencialmente esta acumulación. Entender la diferencia entre logs volátiles (almacenados en memoria RAM bajo /run/log/journal) y logs persistentes (almacenados en disco bajo /var/log/journal) es el primer paso para tomar el control de la retención.

¿Cómo diagnosticar el espacio consumido por los logs de journalctl?

Antes de modificar cualquier archivo de configuración, necesitamos medir el tamaño exacto que los logs de journald están ocupando en el disco duro o SSD del sistema. El propio ecosistema de systemd ofrece herramientas nativas para esta auditoría.

El comando principal para verificar la huella de almacenamiento del journal es journalctl --disk-usage. Al ejecutarlo en la terminal, la utilidad escanea el directorio de almacenamiento y devuelve el total exacto consumido por archivos activos y archivados:

journalctl --disk-usage

La salida de este comando presentará un mensaje similar a:

Archived and active journals take up 4.2G in the file system.

Para obtener una vista detallada de los archivos individuales y verificar si hay contaminación o archivos corruptos, puedes listar directamente el directorio de destino usando las utilidades estándar de la shell de Linux:

sudo du -sh /var/log/journal/*
sudo ls -lh /var/log/journal/$(cat /etc/machine-id)

Otra comprobación útil consiste en inspeccionar el encabezado de las instancias de log para comprender la ventana temporal que cubren esos archivos. Al ejecutar journalctl --header, el sistema muestra los límites del primer y último registro almacenados en el archivo activo, lo que permite identificar si estás manteniendo logs innecesarios de hace seis meses.

Paso a paso: cómo configurar journald para controlar el uso del disco

La forma recomendada de modificar las reglas de systemd-journald no implica editar directamente el archivo principal /etc/systemd/journald.conf, ya que las actualizaciones del sistema operativo pueden sobrescribirlo. En su lugar, la buena práctica moderna en Linux consiste en utilizar directorios de superposición (archivos de configuración drop-in) dentro de /etc/systemd/journald.conf.d/.

Archivo predeterminado de journald.conf:

Sigue los siguientes pasos para aplicar límites estrictos y seguros al consumo de almacenamiento:

1. Crear el directorio de configuraciones personalizadas

Abre la terminal con privilegios de administrador o utiliza sudo para crear el directorio de drop-in si aún no existe:

sudo mkdir -p /etc/systemd/journald.conf.d

2. Crear el archivo de limitación de almacenamiento

Crea un archivo llamado 00-storage-limit.conf utilizando tu editor de texto preferido (como nano o vim):

sudo nano /etc/systemd/journald.conf.d/00-storage-limit.conf

3. Insertar los parámetros de control de cuota

Añade el siguiente bloque de configuración al archivo. Estas directivas le indican a systemd que mantenga el diario en disco, pero restrinja rigurosamente el tamaño máximo global, la cantidad de espacio libre obligatorio y el tamaño de cada archivo individual:

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
SystemMaxFileSize=100M
SystemMaxFiles=10

Comprende la función de cada parámetro definido:

• Storage=persistent: Garantiza que los logs se guarden en el disco bajo /var/log/journal y sobrevivan a los reinicios del sistema.
• SystemMaxUse=1G: Define el límite máximo absoluto que todos los archivos de log combinados pueden ocupar en el sistema de archivos. En este ejemplo, lo limitamos a un máximo de 1 Gigabyte.
• SystemKeepFree=2G: Garantiza que journald nunca usará espacio si el disco tiene menos de 2 Gigabytes libres en la partición.
• SystemMaxFileSize=100M: Restringe el tamaño individual de cada archivo de log binario a 100 Megabytes. Cuando se alcanza este tamaño, el archivo se rota.
• SystemMaxFiles=10: Limita la cantidad total de archivos de log mantenidos (entre activos y archivados) a un máximo de 10 archivos.

4. Validar y aplicar los cambios

Después de guardar y cerrar el archivo, valida que la sintaxis de la configuración sea correcta y reinicia el servicio de systemd-journald para aplicar las nuevas reglas inmediatamente:

sudo systemd-analyze cat journald.conf
sudo systemctl restart systemd-journald

Verifica nuevamente el consumo de disco con el comando journalctl --disk-usage. Systemd aplicará la limpieza automática de inmediato para ajustar los logs a los nuevos límites establecidos.

¿Cómo aplicar límites temporales y de archivos en journald.conf?

Además de definir cuotas basadas en bytes y megabytes, es crucial establecer límites basados en el tiempo de retención de los mensajes. En muchos entornos sujetos a regulaciones de cumplimiento o en servidores de desarrollo, mantener logs durante más de 14 o 30 días es completamente innecesario y desperdicia recursos.

La siguiente tabla resume las principales directivas de tiempo y control de ráfagas disponibles en journald.conf para perfeccionar tu estrategia de retención:

Para incluir el límite temporal de retención de 14 días y configurar la tasa límite contra servicios ruidosos, actualiza tu archivo /etc/systemd/journald.conf.d/00-storage-limit.conf añadiendo las opciones de tiempo:

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
SystemMaxFileSize=100M
MaxRetentionSec=14d
RateLimitIntervalSec=30s
RateLimitBurst=10000

El parámetro RateLimitBurst evita que una aplicación en Python en un bucle infinito de error colapse el subsistema de entrada/salida (I/O) del disco duro al intentar escribir cientos de miles de líneas por segundo.

¿Cómo limpiar journald manualmente sin reiniciar el sistema?

Si tu servidor ya tiene la partición al 100% de uso y necesitas liberar espacio de emergencia antes incluso de configurar los archivos de control permanente, journalctl ofrece opciones de limpieza rápida conocidas como parámetros de vacuuming.

Puedes ejecutar la limpieza de emergencia utilizando criterios de tamaño, tiempo o número de archivos sin interrumpir la ejecución del sistema operativo ni afectar el funcionamiento de tus aplicaciones en ejecución.

Para reducir inmediatamente el tamaño total acumulado en el diario a un valor fijo, utiliza la opción --vacuum-size:

sudo journalctl --vacuum-size=500M

Para eliminar cualquier log que se haya registrado hace más de una semana, utiliza el argumento --vacuum-time:

sudo journalctl --vacuum-time=7d

Si prefieres limitar por la cantidad bruta de archivos archivados restantes, utiliza --vacuum-files:

sudo journalctl --vacuum-files=5

Antes de ejecutar cualquier comando de eliminación por vacuuming, una técnica avanzada importante es forzar a systemd-journald a cerrar el archivo binario activo actualmente y abrir uno nuevo. Esto garantiza que todo el historial reciente se marque como rotado y se pueda limpiar sin bloquear descriptores de archivo abiertos (file descriptors):

sudo journalctl --rotate
sudo journalctl --vacuum-size=500M

Aviso de seguridad: Nunca ejecutes rm -rf /var/log/journal/* manualmente mientras el demonio de systemd esté en ejecución. Eliminar los archivos de log directamente con el comando rm sin avisar al demonio puede causar corrupción en los catálogos de metadatos, dejar descriptores de archivo abiertos apuntando a bloques huérfanos e impedir la grabación de nuevos registros hasta el próximo reinicio del equipo.

Conclusión

Gestionar el almacenamiento de un sistema Linux de forma proactiva es la diferencia entre una infraestructura estable y una caída no planificada en producción. Entender cómo configurar journald permite ajustar con precisión quirúrgica la retención de logs, garantizando que systemd-journald conserve solo la información estrictamente necesaria para diagnósticos sin devorar el espacio en disco.