Ahorra GBs 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 una 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 al utilizar la utilidad journalctl. Sin embargo, la configuración predeterminada por defecto (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 permanente. En un servidor web o en un entorno de desarrollo con 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 que o /var/log/journal cresce sem parar?

El crecimiento desmedido de la carpeta /var/log/journal ocurre debido a la forma en que systemd-journald maneja el ciclo de vida de los archivos de registro. 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 seguirá creando nuevos archivos hasta alcanzar el límite global calculado con base en 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 registros de depuración (stack traces) extensos cada segundo, o depuradores activados en entornos de pruebas 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.

Como diagnosticar o espaço consumido pelos logs do journalctl?

Antes de modificar cualquier archivo de configuración, necesitas 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 los 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 dañados, puedes listar directamente el directorio de destino utilizando las utilidades estándar de la consola Linux:

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

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

Passo a passo: como configurar o journald para controlar o uso do 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 (drop-in configuration files) dentro de /etc/systemd/journald.conf.d/.

Sigue los pasos a continuación para aplicar límites estrictos y seguros al consumo de almacenamiento:

1. Criar o diretório de configurações customizadas

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

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

2. Criar o arquivo de limitação de armazenamento

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. Inserir os parâmetros de controle de quota

Añade el bloque de configuración a continuación dentro del archivo. Estas directivas le indican a systemd que mantenga el diario en disco, pero restringen 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 el papel de cada parámetro definido:

• Storage=persistent: Garantiza que los logs se guarden en el disco en /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 conservados (entre activos y archivados) a un máximo de 10 archivos.

4. Validar e aplicar as alterações

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 de inmediato:

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

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

Como aplicar limites temporais e de arquivos no 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 agregando 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 atrapada en un bucle infinito de errores bloquee el subsistema de E/S (I/O) del disco duro al intentar escribir cientos de miles de líneas por segundo.

Como limpar o journald manualmente sem reiniciar o 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 depuración (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 registrado hace más de una semana, utiliza el argumento --vacuum-time:

sudo journalctl --vacuum-time=7d

En caso de que prefieras limitar 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 consiste en forzar a systemd-journald a cerrar el archivo binario activo e iniciar uno nuevo. Esto garantiza que todo el historial reciente quede marcado como rotado y se pueda limpiar sin bloquear descriptores de archivos 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 notificar al demonio puede causar corrupción en los catálogos de metadatos, dejar descriptores de archivos abiertos apuntando a bloques huérfanos e impedir el registro de nuevos eventos hasta el próximo reinicio del equipo.

Conclusão

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 te permite ajustar con precisión quirúrgica la retención de logs, garantizando que systemd-journald conserve únicamente la información estrictamente necesaria para diagnósticos sin devorar el espacio en disco.

Al aplicar límites con SystemMaxUse, restringir la retención temporal con MaxRetentionSec y utilizar archivos de configuración en /etc/systemd/journald.conf.d/, transformas el mantenimiento de servidores Debian 13.7 y Ubuntu 26.04.1 en un proceso automatizado y predecible. Adopta estas directivas en tus imágenes base de servidor y evita para siempre el pánico de particiones llenas por acumulación de logs.