Deux ans sans redémarrer, ça paraît être une victoire d’admin sys. Mais c’est exactement ce qui m’a explosé au visage un mardi matin, quand mon serveur perso a refusé de rebooter après une coupure de courant. Le coupable ? Un dossier /var/log/journal qui pesait plus de 4 Go, gonflé par deux années de logs systemd que je pensais, à tort, autonettoyés.
Le mythe est tenace : beaucoup d’utilisateurs Linux imaginent que journald gère tout seul son ménage, sans jamais vérifier les chiffres. En théorie, ce n’est pas totalement faux. Les options SystemMaxUse et RuntimeMaxUse limitent l’espace disque que le journal peut utiliser, avec un défaut de 10% de la taille du système de fichiers, plafonné à 4 Go. Les options SystemKeepFree et RuntimeKeepFree définissent l’espace laissé libre, à hauteur de 15%, également plafonné à 4 Go. Sur le papier, tout semble verrouillé. Dans la pratique, ce plafond de 4 Go n’est pas une garantie de « petit journal propre », c’est juste le montant maximal que systemd s’autorise à consommer avant de faire quoi que ce soit.
À retenir
- Les limites par défaut de systemd journald ne garantissent pas un nettoyage régulier : elles définissent juste le plafond avant action
- Le fichier journal actif en cours d’écriture échappe aux commandes de nettoyage, ce qui peut créer une accumulation invisible pendant des mois
- Même avec une configuration stricte, journald reste passif si d’autres processus consomment l’espace libre : il n’efface rien de lui-même
Pourquoi journald a laissé filer jusqu’à saturation
La confusion vient d’un détail que peu de gens lisent jusqu’au bout dans la documentation officielle. Le journal systemd retient par défaut 4 Go de données, et pour augmenter ou diminuer cette valeur, il faut configurer SystemMaxUse et éventuellement SystemKeepFree, qui définit la borne supérieure d’espace laissé libre sur le disque. Le mot clé, c’est « retient ». Pas « nettoie proprement au fil de l’eau ». Systemd attend d’atteindre la limite avant de commencer à faire le tri, et encore, pas n’importe comment.
Le vrai piège technique, celui qui m’a vraiment coincé, tient dans un comportement documenté par le projet systemd lui-même. Si le système de fichiers est presque plein et que la limite de KeepFree est violée au démarrage de journald, la limite est relevée au pourcentage réellement disponible, ce qui signifie que si le disque se remplit ensuite pour une autre raison, journald arrêtera d’utiliser plus d’espace mais ne supprimera pas les fichiers existants pour réduire son empreinte. Une fois que d’autres processus (mises à jour, caches applicatifs, dumps de conteneurs) ont mangé l’espace libre restant, journald se contente de ne plus écrire, sans faire le moindre geste pour libérer de la place. Il reste passif, les bras croisés devant 4 Go de vieux logs.
Et il y a pire : même quand on tente de forcer le ménage à la main, ça ne marche pas toujours comme prévu. Seuls les fichiers archivés sont supprimés pour réduire l’espace occupé, ce qui signifie qu’en pratique il peut rester plus d’espace utilisé que la limite configurée même après une opération de vacuuming. Le fichier journal « actif » du moment, celui en cours d’écriture, n’est jamais touché par les commandes de nettoyage. Sur un serveur qui tourne sans interruption pendant deux ans, ce fichier actif peut lui-même devenir énorme avant même de songer à être archivé.
Le jour où le disque a dit stop
Mon serveur, un petit boîtier qui héberge quelques services persos, tournait sur une partition racine modeste. Avec 4 Go bloqués par les journaux systemd en plus de deux ans d’accumulation de paquets, de caches et de conteneurs jamais purgés, il ne restait littéralement plus assez d’espace pour que le processus d’initialisation écrive ses propres fichiers temporaires au boot. Résultat : écran figé, aucun message d’erreur clair, juste un silence radio numérique assez flippant à 7h du matin avant le café.
Ce genre de panne n’est pas isolé. Des cas similaires circulent régulièrement dans la communauté sysadmin, notamment sur des systèmes RHEL où malgré une configuration SystemMaxUse fixée à 330 Mo, les journaux archivés et actifs occupaient 2,8 Go sur le disque, bien au-delà de la limite censée s’appliquer. Le bug ou le comportement inattendu n’est donc pas propre à mon setup : c’est un angle mort assez commun de journald, surtout sur les configurations qui datent d’avant les dernières refontes du démon.
Comment j’ai débloqué la machine, et ce que j’ai changé pour de bon
Pour repartir, j’ai dû booter sur un live USB, monter la partition défaillante, et libérer de l’espace manuellement avant même de pouvoir relancer le système normalement. Une fois le serveur de nouveau accessible, la première commande a été un diagnostic simple : vérifier combien d’espace le journal occupait réellement, puis lancer un nettoyage ciblé. La commande –vacuum-size supprime les fichiers journaux archivés les plus anciens jusqu’à ce que l’espace disque qu’ils utilisent tombe sous la taille spécifiée. En quelques secondes, j’ai récupéré plus de 3,5 Go.
Mais nettoyer une fois ne résout rien si la config reste identique. J’ai donc réécrit mon fichier /etc/systemd/journald.conf avec des valeurs réalistes pour un petit serveur : une limite basse, une rétention par durée plutôt que par taille pure, et surtout une vérification régulière plutôt qu’une confiance aveugle. Sur les distributions récentes, il est aussi possible de forcer une rotation explicite avant le vacuum, ce qui garantit que même le fichier actif est pris en compte dans le nettoyage. La leçon est simple, presque bête : journald n’est pas un système « fire and forget ». C’est un outil puissant, bien pensé, mais qui a besoin qu’on lui dise explicitement où sont ses limites, sans quoi il applique les siennes par défaut, capées large, et attend patiemment que le problème explose ailleurs.
Depuis, j’ai ajouté une simple tâche cron qui vérifie l’usage disque du journal chaque semaine et m’envoie une alerte si ça dépasse un seuil raisonnable. Ça prend trente secondes à mettre en place et ça évite de refaire connaissance avec un live USB à 7h du matin. Si vous gérez un serveur Linux qui tourne depuis plus de quelques mois sans reboot, allez vérifier journalctl --disk-usage tout de suite. Sérieusement, maintenant.
Sources : linux-audit.com | access.redhat.com