mrsaynothing.dev
journalctl: uso de disco — vacuum achica, SystemMaxUse tapa
Uso de disco de journalctl con recibos: qué cuenta --disk-usage, por qué --vacuum-size se vuelve a llenar y el drop-in que cierra el grifo. Medido, con cura.
SystemMaxUse es la válvula de la tubería.¿Qué mide realmente journalctl --disk-usage?
La frase-verdad: journalctl --disk-usage informa el tamaño de tus archivos de journal en disco — archivados y activos — que viven en /var/log/journal en toda instalación persistente. Es una lectura: no borra nada, no reinicia nada. En la VM de banco, antes de añadir ningún log:
$ sudo journalctl --disk-usage
Archived and active journals take up 48.2M in the file system.
$ ls /var/log/journal/
fd766b9ea5a540e68e6c43ea74f98a15 ← one directory per machine-idverifica: el Arch de fábrica trae /var/log/journal presente — Storage=auto (el default comentado #Storage=persistent) significa persistente desde el primer arranque. Córralo con sudo: sin pertenecer a adm/systemd-journal/wheel, la lectura de un usuario común cubre solo sus propios archivos — el banco midió 16M como usuario y 48.2M como root en el mismo segundo.
Dos cosas hacen tropezar a la gente aquí. Primera: el número incluye el journal activo — el archivo en el que journald está escribiendo ahora mismo — así que ni un arranque recién hecho da cero. Segunda: si /var/log/journal no existe, journald es volátil: todo vive en /run/log/journal (tmpfs), las lecturas dan casi cero, y muere al reiniciar. Eso no es «un journal pequeño» — es no tener historial de journal alguno. sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald te pasa a persistente.
¿Por qué el journal no deja de crecer?
Porque el grifo viene abierto de fábrica. El /etc/systemd/journald.conf de origen trae comentado cada control de tamaño:
$ grep -E '^#(Storage|Compress|SystemMaxUse)' /etc/systemd/journald.conf
#Storage=persistent
#Compress=yes
#SystemMaxUse=verifica: pegado tal cual de la máquina de banco — SystemMaxUse existe en el archivo solo como comentario; journald lo lee como sin definir y no impone techo alguno.
Sin techo, nada envejece fuera y nada se acota: un servicio parlanchín o un cron ruidoso añaden megas por día, para siempre. El banco probó la pendiente a la manera honesta — ráfaga, rotación forzada, y releer el medidor:
$ for i in $(seq 1 400); do logger -t benchflood "entry $i: …~1KB line…"; done
$ sudo journalctl -t benchflood --no-pager | wc -l # all 400 landed
400
$ sudo journalctl --rotate # close the active file
$ sudo journalctl --disk-usage
Archived and active journals take up 56.2M in the file system.verifica: 48.2M → 56.2M con una sola ráfaga pequeña. Ahí van escondidos dos recibos: el crecimiento solo se hace visible en la rotación — journald preasigna el archivo activo en bloques de 8M, así que las ráfagas a mitad de archivo no mueven el medidor hasta que el archivo se cierra — y du -sh /var/log/journal (57M) coincide con el número del propio journald dentro del redondeo.
La ráfaga fueron 400 líneas de un kilobyte — un error de redondeo frente al ruido diario de una máquina real. El tamaño no es el punto; la dirección sí: sin tope, el único estado estable es «más», en pasos de 8M que nunca elegiste.
¿journalctl --vacuum-size lo borra para siempre?
No — y la confesión está impresa en la salida del propio comando. Vacuum es el balde de achique: un cucharón, satisfacción inmediata, estructuralmente nada:
$ sudo journalctl --vacuum-size=1M
Deleted archived journal …/system@…-adf16c8ac48706f4.journal~ (8M).
Deleted archived journal …/system@d1d286….journal (8.2M).
Deleted archived journal …/user-1000@…journal~ (8M).
Deleted archived journal …/system@…c3f9281226bbfdc4.journal~ (8M).
Deleted archived journal …/system@…5244-….journal (4.4M).
Deleted archived journal …/user-1000@…57b6-….journal (3.4M).
Deleted archived journal …/system@…59c8-….journal (976K).
Deleted archived journal …/user-1000@…59cb-….journal (296K).
Vacuuming done, freed 41.4M of archived journals from /var/log/journal/fd766b9e….
$ sudo journalctl --disk-usage
Archived and active journals take up 16M in the file system.verifica: la lista de borrados y «Vacuuming done, freed 41.4M» son el stdout del propio --vacuum-size, pegados verbatim — 56.2M cayó a 16M.
Mira fijo el piso, porque es la parte que los crons nunca ven: 16M se quedaron. Son los dos archivos de journal activos — system.journal y user-1000.journal, preasignados a 8M cada uno — y --vacuum-size solo borra archivos archivados. Vacuum no puede cortar por debajo de lo que journald está escribiendo ahora, por chico que sea el número que le pases.
Después la prueba del relleno — la parte que nadie corre. La misma ráfaga otra vez, rotar, leer:
$ sudo journalctl --disk-usage
Archived and active journals take up 20.3M in the file system.
$ sudo du -sh /var/log/journal
21M /var/log/journalverifica: 16M → 20.3M con una ráfaga idéntica de 400 líneas — vacuum borró historia; del mañana no cambió nada.
Por eso el cron de vacuum es el remedio casero que nunca termina de funcionar: pelea contra el grifo con un balde, a horario, para siempre. Si el cron corre --vacuum-size=100M cada semana y el journal llega a 1G a mitad de semana, los lectores pagan el 1G toda la semana. Y cada pasada es un evento de pérdida de datos silencioso — las líneas liberadas son las más viejas, justo la historia que buscas durante un incidente.
¿Cómo limitas el tamaño del journal para siempre?
Un drop-in, un reinicio — y desde ahí journald impone el techo él mismo, en cada rotación, para siempre:
$ sudo mkdir -p /etc/systemd/journald.conf.d
$ sudo tee /etc/systemd/journald.conf.d/size.conf >/dev/null <<'EOF'
[Journal]
SystemMaxUse=5M
EOF
$ sudo systemctl restart systemd-journald
$ sudo systemd-analyze cat-config systemd/journald.conf | grep SystemMaxUse
SystemMaxUse=5Mverifica: systemd-analyze cat-config imprime la config FUSIONADA — el SystemMaxUse=5M del drop-in está vivo, no solo escrito en un archivo que nadie lee.
Ahora la ráfaga idéntica que levantó al journal vaciado hasta 20.3M:
$ for i in $(seq 1 400); do logger -t benchflood "entry $i: …"; done
$ sudo journalctl --rotate
$ sudo journalctl --disk-usage
Archived and active journals take up 1.2M in the file system.
$ sudo ls -lh /var/log/journal/*/ | awk '{print $5, $9}'
640K system.journal
640K user-1000.journal
$ sudo journalctl -t benchflood --no-pager | wc -l
0verifica: la misma ráfaga que llevó un journal sin tope a 20.3M dejó al con tope en 1.2M — journald rotó, aplicó el techo y borró la ráfaga sin más: 400 entradas dentro, 0 retenidas, sin cron, sin supervisión.
Fíjate en lo que el tope hizo y el vacuum no pudo: bajar del piso de 16M. Vacuum jamás toca los archivos activos, pero el tope gobierna la rotación misma — journald reconstruye archivos activos más chicos en cuanto el techo está vivo. Esa es la diferencia entre achicar y arreglar la tubería.
Elige tu número por margen, no por gusto: mira el tamaño de hoy con journalctl --disk-usage, y pon SystemMaxUse más o menos en lo máximo que quieras conservar — 100M o 200M sobran para una estación de trabajo; un servidor ocupado quizá quiera 1G. SystemKeepFree=1G es el hermano del cinturón y los tirantes: limita el journal y además le promete un piso al filesystem. Lo borrado son siempre los archivos archivados más viejos — journald se queda el archivo activo y lo que quepa bajo tu techo.
La cura, en orden
Achique vs válvula, de un vistazo
| herramienta | qué hace | cuándo ayuda | medido en el banco |
|---|---|---|---|
--vacuum-size=1M | borra los journals archivados más viejos hasta un tamaño, una vez | emergencia: disco lleno ahora | 56.2M → 16M (liberó 41.4M), rellenado a 20.3M por la siguiente ráfaga idéntica |
--vacuum-time=2weeks | lo mismo, por antigüedad en vez de tamaño | limpieza de archivo de una sola vez | la misma forma de un solo tiro — nada frena el recrecimiento |
drop-in SystemMaxUse=5M | journald se impone un techo a sí mismo en cada rotación | permanente: el grifo se cierra | ráfaga idéntica sostenida en 1.2M — entradas de la ráfaga borradas sin más (400 dentro, 0 guardadas) |
SystemKeepFree=1G | le promete espacio libre al filesystem, con o sin tope | discos chicos, junto al tope | el espíritu del default de fábrica, ahora explícito |
«Vacuum achica la bañera; SystemMaxUse cierra el grifo. Todos achican — la bañera gana por default.»
lo que el banco no cubrió
Medido: una VM Arch recién creada (systemd 262, 262.1-1-arch) — uso de línea base, una ráfaga de 400 líneas con rotación forzada, --vacuum-size=1M con su stdout completo, una ráfaga de relleno idéntica, el drop-in SystemMaxUse=5M + reinicio con relectura de la config fusionada, una ráfaga idéntica bajo el tope, y testigos a nivel de archivo con du/ls en cada paso. No medido: la interacción de SystemMaxFileSize/conteo de archivos bajo el techo, los journals por-unidad de LogNamespace=, el logging remoto (systemd-journal-remote), el sellado forward-secure (Seal=) y la retención por tiempo (MaxRetentionSec). Las líneas de la ráfaga viajaron por el socket syslog, que trunca líneas largas (~1 KB entraron) — irrelevante para la contabilidad, porque cada número de arriba es el --disk-usage del propio journald cotejado contra du. La línea base traía archivados de un arranque anterior (un 48.2M ya vivido, como cualquier máquina real). Una máquina, una build: la lectura grifo-contra-balde es la parte portable; tu propio --disk-usage es el veredicto.
BANCO VERIFICADO A MANO · systemd 262 (262.1-1-arch) · VM Arch recién creada · última prueba 2026-11-12
Un número te dice la verdad — journalctl --disk-usage. Una línea lo mantiene verdadero — SystemMaxUse. Cierra el grifo; jubila el balde. ■