Tecnología · GUÍA PRÁCTICA
¿journalctl vacuum liberó 0B? Rota los diarios activos y comprende el mínimo de espacio ocupado
Distingue los archivos de diario activos de los archivados, elige el límite correspondiente al almacenamiento persistente o volátil y comprueba por qué el uso puede seguir por encima del objetivo solicitado.
Un vacuum de journalctl puede ejecutarse correctamente y liberar 0B o dejar el uso de disco por encima del tamaño solicitado sin que haya un fallo. El uso mostrado incluye archivos de diario activos y archivados, mientras que vacuum solo elimina los archivados. Rota primero si necesitas que una limpieza puntual incluya los datos escritos hasta ese momento.
Una limpieza puntual con vacuum es distinta de un límite de almacenamiento para el futuro. Los diarios persistentes de /var/log/journal usan ajustes System; los diarios volátiles de /run/log/journal usan ajustes Runtime. Incluso con un límite correcto, un diario activo y la granularidad del tamaño de los archivos pueden mantener el total por encima del valor nominal.
1. Registra el estado inicial antes de borrar nada
Ejecuta sudo journalctl --disk-usage y guarda la salida. Después, revisa las salidas de sudo du -sh /var/log/journal /run/log/journal 2>/dev/null y sudo journalctl --list-boots. El primer comando muestra el uso desde la perspectiva del diario; la comprobación de los directorios indica si el almacenamiento pertinente es persistente, volátil o ambos. No deduzcas el tipo de almacenamiento solo por el nombre de la distribución.
Antes de limpiar, conserva los registros necesarios para un incidente, una auditoría o un caso de soporte. Este procedimiento gestiona el almacenamiento local del diario; no abarca la retención de journal-remote, los archivos exportados ni los archivos copiados fuera de la jerarquía de directorios del diario en uso.
2. Explica el resultado de 0B antes de cambiar la configuración
El manual del proyecto indica que --disk-usage incluye archivos activos y archivados, pero vacuum actúa sobre los archivados. Si el almacenamiento solo contiene un archivo activo, un objetivo pequeño aún puede liberar 0B. El ejemplo de Server Fault muestra precisamente este patrón y solo libera espacio más adelante, cuando ya existen archivos archivados.
No uses --vacuum-size=0 como atajo para vaciarlo todo. La documentación actual de systemd define cero como la ausencia de límite para ese criterio. Elige un objetivo distinto de cero que conserve suficiente historial para diagnosticar tu sistema.
3. Realiza una limpieza puntual con un alcance definido
Para incluir los datos escritos hasta ese momento, ejecuta sudo journalctl --rotate --vacuum-size=500M y sustituye 500M por el objetivo que hayas evaluado. Al combinar las opciones, primero se rotan los archivos activos y después se aplica vacuum a los archivados. Evita borrar manualmente archivos .journal mientras journald los esté usando.
Vuelve a ejecutar sudo journalctl --disk-usage y registra tanto el mensaje de bytes liberados como el nuevo total. Que siga habiendo espacio ocupado no indica automáticamente un fallo: permanece un archivo activo nuevo y también pueden contribuir otros espacios de nombres o almacenes.
4. Elige el límite correcto a largo plazo
Para el almacenamiento persistente de /var/log/journal, configura SystemMaxUse en un archivo local de configuración complementaria, o drop-in, de journald.conf. Si necesitas una granularidad de borrado más fina, configura también SystemMaxFileSize. Para el almacenamiento volátil de /run/log/journal, usa RuntimeMaxUse y RuntimeMaxFileSize. SystemKeepFree y RuntimeKeepFree reservan espacio libre; journald aplica el menor de los límites pertinentes.
Red Hat documenta por separado cómo habilitar el diario persistente y verifica que /var/log/journal exista y contenga archivos. En sistemas donde se aplica Storage=auto, la presencia de ese directorio importa. Sigue el mecanismo de configuración y las herramientas de validación de tu distribución, en lugar de copiar sin comprobar un ejemplo específico de un rol de sistema.
5. Aplica y verifica la configuración
Después de añadir un drop-in local, valida la configuración efectiva con las herramientas disponibles en tu distribución, recarga o reinicia systemd-journald según el procedimiento admitido y confirma el directorio de almacenamiento esperado. Después, genera registros normales, espera a la rotación cuando corresponda y vuelve a comprobar el uso de disco. Un archivo con sintaxis válida aún puede estar dirigido al tipo de almacenamiento equivocado.
Prueba el estado estable, no solo la limpieza inmediata. Registra el tamaño del archivo activo, el total archivado, los valores configurados de MaxUse y MaxFileSize y el espacio libre. Así podrás distinguir un problema real de crecimiento del mínimo impuesto por el archivo activo o de la granularidad gruesa del tamaño de los archivos, comportamientos descritos en la documentación.
6. Entiende qué demuestra este resultado
El resultado de rotar y aplicar vacuum solo demuestra que los archivos locales de diario archivados que cumplían los requisitos se tuvieron en cuenta según los criterios elegidos. No demuestra que todos los registros de las aplicaciones se guarden en journald, que se hayan depurado los archivos remotos ni que se haya configurado un límite para el futuro.
Si el uso sigue creciendo por encima del intervalo esperado en estado estable, recoge los directorios reales, los tamaños de los archivos activos y archivados, los espacios de nombres del diario, la configuración efectiva y la versión de systemd. No sigas reduciendo el objetivo hasta que las pruebas identifiquen qué componente consume el espacio.
