mrsaynothing.dev
Usage disque journalctl — vacuum écope, SystemMaxUse ferme
Usage disque de journalctl, avec preuves : ce que compte --disk-usage, pourquoi --vacuum-size se regonfle, et le drop-in qui ferme le robinet pour de bon.
SystemMaxUse est la vanne sur le tuyau.Que mesure réellement journalctl --disk-usage ?
La phrase à retenir : journalctl --disk-usage rapporte la taille de tes fichiers de journal sur disque — archivés et actifs — qui vivent dans /var/log/journal sur toute installation persistante. C'est une lecture : il ne supprime rien, ne redémarre rien. Sur la VM du banc, avant tout ajout de logs :
$ 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-idvérif : Arch d'origine livre /var/log/journal présent — Storage=auto (le défaut commenté #Storage=persistent) signifie persistant dès le premier boot. Lance-le avec sudo : sans appartenance à adm/systemd-journal/wheel, la lecture d'un utilisateur lambda ne couvre que ses propres fichiers — le banc a mesuré 16M en tant qu'utilisateur et 48.2M en tant que root à la même seconde.
Deux choses piègent ici. D'abord, le chiffre inclut le journal actif — le fichier dans lequel journald écrit en ce moment — donc même un boot frais n'est jamais à zéro. Ensuite, si /var/log/journal n'existe pas, journald est volatil : tout vit dans /run/log/journal (tmpfs), la lecture frôle zéro, et tout meurt au reboot. Ce n'est pas « un petit journal » — c'est aucun historique de journal du tout. sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald te bascule en persistant.
Pourquoi le journal ne cesse de grossir ?
Parce que le robinet est ouvert par conception. La /etc/systemd/journald.conf d'origine livre chaque molette de taille commentée :
$ grep -E '^#(Storage|Compress|SystemMaxUse)' /etc/systemd/journald.conf
#Storage=persistent
#Compress=yes
#SystemMaxUse=vérif : copié depuis la machine du banc — SystemMaxUse n'existe dans le fichier qu'en commentaire ; journald le lit comme non défini et n'impose aucun plafond.
Sans plafond, rien ne vieillit et rien ne bride : un service bavard ou un cron bruyant ajoute des mégaoctets par jour, pour toujours. Le banc a prouvé la pente à la manière honnête — inonder, forcer une rotation, relire le compteur :
$ 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.vérif : 48.2M → 56.2M à partir d'une seule petite crue. Deux reçus se cachent là : la croissance ne devient visible qu'à la rotation — journald pré-alloue le fichier actif par blocs de 8M, donc les crues en plein fichier ne bougent pas le compteur tant que le fichier n'est pas fermé — et du -sh /var/log/journal (57M) s'accorde avec le chiffre de journald lui-même à l'arrondi près.
La crue faisait 400 lignes d'un kilooctet — une erreur d'arrondi face au bruit quotidien d'une vraie machine. La taille n'est pas le propos ; la direction l'est : sans plafond, le seul état stable est « plus », par pas de 8M que tu n'as jamais choisis.
journalctl --vacuum-size supprime-t-il pour de bon ?
Non — et l'aveu est imprimé dans la sortie même de la commande. Le vacuum est le seau : une écope, satisfaction immédiate, structurellement rien :
$ 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.vérif : la liste des suppressions et « Vacuuming done, freed 41.4M » sont la sortie stdout propre de --vacuum-size, copiée verbatim — 56.2M est tombé à 16M.
Regarde bien le plancher, car c'est la partie que les crons ne remarquent jamais : 16M sont restés. Ce sont les deux fichiers de journal actifs — system.journal et user-1000.journal, pré-alloués 8M chacun — et --vacuum-size ne supprime jamais que des fichiers archivés. Le vacuum ne peut pas couper sous ce dans quoi journald écrit en ce moment, si petit que soit le chiffre que tu lui passes.
Puis le test du regonflage — la partie que personne ne lance. La même crue encore, rotation, lecture :
$ 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/journalvérif : 16M → 20.3M à partir d'une crue identique de 400 lignes — le vacuum a supprimé l'historique ; il n'a rien changé à demain.
C'est pourquoi le cron de vacuum est un remède de grand-mère qui ne marche jamais tout à fait : il combat le robinet avec un seau, à horaire fixe, pour toujours. Si le cron lance --vacuum-size=100M chaque semaine et que le journal atteint 1G en milieu de semaine, les lecteurs paient le 1G toute la semaine. Et chaque passe est un évènement discret de perte de données — les lignes libérées sont les plus vieilles, exactement l'historique où tu plonges pendant un incident.
Comment plafonner la taille du journal pour toujours ?
Un drop-in, un redémarrage — puis journald impose le plafond lui-même, à chaque rotation, pour toujours :
$ 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=5Mvérif : systemd-analyze cat-config affiche la config FUSIONNÉE — le SystemMaxUse=5M du drop-in est vivant, pas seulement écrit dans un fichier que personne ne lit.
Maintenant, la crue identique qui avait fait monter le journal vacuumé à 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
0vérif : la même crue qui a fait monter un journal sans plafond à 20.3M a laissé le journal plafonné à 1.2M — journald a tourné, appliqué le plafond et supprimé la crue net : 400 entrées rentrées, 0 retenues, pas de cron, pas de supervision.
Note ce que le plafond a fait et que le vacuum ne pouvait pas : passer sous le plancher de 16M. Le vacuum ne touche jamais les fichiers actifs, mais le plafond gouverne la rotation elle-même — journald reconstruit des fichiers actifs plus petits une fois le plafond vivant. C'est la différence entre écopage et plomberie.
Choisis ton chiffre par la marge, pas par le goût : vérifie la taille du jour avec journalctl --disk-usage, puis mets SystemMaxUse à peu près au maximum que tu veux garder — 100M ou 200M suffit largement pour une station de travail ; un serveur chargé voudra peut-être 1G. SystemKeepFree=1G est le frère ceinture-et-bretelles : plafonner le journal et promettre un plancher au système de fichiers. Le matériel supprimé est toujours les plus vieux fichiers archivés — journald garde le fichier actif et ce qui tient sous ton plafond.
Le remède, dans l'ordre
Écope contre vanne, d'un coup d'œil
| outil | ce qu'il fait | quand il aide | mesuré au banc |
|---|---|---|---|
--vacuum-size=1M | supprime les plus vieux journaux archivés jusqu'à une taille, une fois | urgence : disque plein maintenant | 56.2M → 16M (41.4M libérés), regonflé à 20.3M par la prochaine crue identique |
--vacuum-time=2weeks | pareil, par l'âge au lieu de la taille | nettoyage d'archive ponctuel | même forme one-shot — rien n'arrête la repousse |
SystemMaxUse=5M drop-in | journald s'impose lui-même un plafond à chaque rotation | permanent : le robinet se ferme | crue identique tenue à 1.2M — entrées de la crue supprimées net (400 rentrées, 0 gardées) |
SystemKeepFree=1G | promet de l'espace libre au système de fichiers, plafond ou pas | petits disques, aux côtés du plafond | esprit du défaut d'origine, désormais explicite |
« Le vacuum écope la baignoire ; SystemMaxUse ferme le robinet. Tout le monde écope — la baignoire gagne par défaut. »
ce que le banc n'a pas couvert
Mesuré : une VM Arch vierge (systemd 262, 262.1-1-arch) — l'usage de base, une crue de 400 lignes avec rotation forcée, --vacuum-size=1M avec sa sortie stdout complète, une crue de regonflage identique, le drop-in SystemMaxUse=5M + redémarrage avec relecture de la config fusionnée, une crue identique sous le plafond, et des témoins du/ls au niveau fichier à chaque étape. Non mesuré : l'interaction SystemMaxFileSize/nombre de fichiers sous le plafond, les journaux par-unité LogNamespace=, le logging distant (systemd-journal-remote), le scellage à confidentialité forward (Seal=), et la rétention temporelle (MaxRetentionSec). Les lignes de la crue ont emprunté le socket syslog, qui tronque les lignes longues (~1 KB arrivés) — sans incidence sur la comptabilité, puisque chaque chiffre ci-dessus est le --disk-usage de journald lui-même, recoupé avec du. La ligne de base portait les archives d'un boot précédent (un 48.2M vécu, comme toute vraie machine). Une machine, une build : la lecture robinet-contre-écope est la partie portable ; ton propre --disk-usage est le verdict.
BANC VÉRIFIÉ À LA MAIN · systemd 262 (262.1-1-arch) · VM Arch vierge · dernier test 2026-11-12
Un seul chiffre te dit la vérité — journalctl --disk-usage. Une seule ligne le garde vrai — SystemMaxUse. Ferme le robinet ; mets le seau au repos. ■