Comment résoudre le problème d'un journal systemd plein

Le journal systemd stocke tous les messages de journal générés par votre serveur, et sur un VPS doté d'une petite partition racine, il peut discrètement épuiser votre espace disque disponible. Lorsque cela se produit, les services ne démarrent pas, les écritures sont bloquées et vous perdez les diagnostics dont vous avez justement besoin pour déterminer ce qui ne va pas. Ce guide explique comment diagnostiquer le problème, libérer de l'espace immédiatement et configurer journald pour que cela ne se reproduise plus.

Diagnostic du problème

Commencez par vérifier l'espace utilisé par le journal :

journalctl --disk-usage

Cette commande indique la taille combinée de tous les fichiers journaux actifs et archivés. Comparez ce chiffre à votre espace disque disponible à l'aide de df -h. Sur une partition racine de 20 Go, même 2 Go de journaux représentent plus de 10 % de l'espace disque total, ce qui est suffisant pour causer des problèmes.

Ensuite, identifiez les services qui génèrent le plus de bruit. Cette ligne de commande classe les 10 principales sources de journaux des dernières 24 heures :

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Filtrez spécifiquement les erreurs avec journalctl -p err -b pour voir si un service est bloqué dans une boucle de plantage et inonde le journal. Vous pouvez également vérifier si journald limite le débit de certains services :

journalctl -u systemd-journald | grep -i "suppressed"

Les messages de suppression indiquent qu'un service a dépassé le seuil par défaut de 10 000 entrées en 30 secondes. C'est votre coupable.

Certains problèmes sont particulièrement fréquents sur les instances VPS. Si Storage=auto est défini et /var/log/journal/ existe, journald utilise un stockage persistant avec une limite par défaut d'environ 4 Go. Sur une petite partition racine, cela se remplit rapidement. Les arrêts non contrôlés peuvent également laisser des fichiers de journalisation corrompus avec un .journal~ . Ces fichiers ne sont pas remplacés normalement et continuent de consommer de l'espace.

Effacer les journaux en toute sécurité

Avant de supprimer quoi que ce soit, effectuez une rotation du fichier journal actif afin de conserver les journaux actuels :

journalctl --rotate

Nettoyez ensuite les journaux archivés. Vous pouvez cibler par date, taille ou nombre de fichiers :

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

La première commande supprime les journaux datant de plus de 24 heures. La deuxième réduit la taille totale du journal à 100 Mo. La troisième ne conserve que les cinq fichiers archivés les plus récents. Choisissez celle qui correspond à votre situation.

Si le disque est complètement plein et que les commandes journalctl ne répondent pas, vous devrez peut-être supprimer les fichiers journaux manuellement :

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Il s'agit d'un dernier recours. Cela efface tous les journaux stockés et recrée le répertoire avec les permissions correctes. Après tout nettoyage, redémarrez le démon et vérifiez :

sudo systemctl restart systemd-journald
journalctl --disk-usage

Configuration des limites de taille de Journald

Les paramètres par défaut de journald sont généreux. Sur un VPS, ils sont trop généreux. Modifiez la configuration pour définir des limites strictes pour le stockage des journaux. Créez un fichier de remplacement plutôt que de modifier directement la configuration principale, afin que vos modifications soient conservées lors des mises à jour des paquets :

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

Les directives clés :

Réglage des deux SystemMaxUse et SystemKeepFree vous offre une approche doublement sécurisée : les journaux sont limités à une taille fixe, et le système dispose toujours d'une marge de manœuvre, quel que soit le contenu du disque.

Stockage persistant vs stockage volatile

La Storage= contrôle l'emplacement des journaux. Définissez Storage=persistent sur pour écrire les journaux /var/log/journal/ sur le disque. C'est ce qu'il faut pour les serveurs de production, car les journaux survivent aux redémarrages et vous pouvez analyser les plantages a posteriori. Si le répertoire n'existe pas, créez-le :

sudo mkdir -p /var/log/journal

L'alternative, Storage=volatileconsiste à conserver les journaux en mémoire vive (RAM) /run/log/journal/. Les journaux disparaissent au redémarrage. Cette option est utile pour les conteneurs éphémères ou les serveurs qui transfèrent tous les journaux vers un système externe.

Désactivation de la compression sur les serveurs à fort trafic

Journald compresse par défaut les objets de données supérieurs à 512 octets. Sur les serveurs traitant un débit de journaux important, cela ajoute une charge supplémentaire au processeur. Définissez Compress=no si vous transférez les journaux vers un système externe et que vous n'avez pas besoin de réduire le stockage local. Configurez également ForwardToConsole=no en production. Le transfert vers la console est synchrone, et une console série virtuelle bloquée peut bloquer complètement le démon journald.

Après toute modification de configuration, redémarrez le service :

sudo systemctl restart systemd-journald

Automatisation de la maintenance des journaux

Le nettoyage manuel n'est pas évolutif. Créez une minuterie systemd pour vider les journaux selon un calendrier défini. Configurez une unité de service à l'adresse /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Créez ensuite une minuterie correspondante à /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Activez-la avec sudo systemctl enable --now journal-vacuum.timer. La minuterie s'exécute tous les dimanches à 2 h du matin et applique à la fois une conservation basée sur la durée et sur la taille en un seul passage.

Il y a toutefois une chose que la minuterie ne détectera pas : les fichiers de journalisation corrompus. Après un arrêt non correct, journald met en quarantaine les fichiers endommagés en ajoutant un ~ au nom du fichier. Ces .journal~ fichiers continuent de compter dans l'utilisation du disque, mais ne seront pas automatiquement nettoyés. Vérifiez-les et supprimez les anciens régulièrement :

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Transfert des journaux vers un système externe

Pour les serveurs nécessitant une conservation à long terme sans augmenter le stockage local, transférez les journaux vers un système centralisé. L'approche la plus simple consiste à activer le transfert syslog dans journald.conf:

ForwardToSyslog=yes

Pour les journaux structurés avec des métadonnées complètes (PID, UID, noms d'unités), utilisez systemd-journal-remote pour envoyer les entrées au format JSON vers une plateforme de gestion des journaux. Le stockage externe des journaux protège également votre piste d’audit en cas de défaillance du disque local ou de compromission du serveur.

Conclusion

Il est simple de corriger un journal systemd plein et facile de l'éviter. Les étapes clés :

• Vérifier l'utilisation avec journalctl --disk-usage et identifiez les services bruyants.
• Libérez immédiatement de l'espace avec journalctl --rotate suivi de --vacuum-size ou --vacuum-time.
• Définissez des limites de taille explicites dans un fichier de remplacement journald.conf.
• Automatisez le nettoyage à l'aide d'une minuterie systemd.
• Transférez les journaux vers un serveur externe pour une conservation à long terme.

Les offres de serveurs VPS et dédiés de FDC fournissent les performances d'E/S disque et la capacité de stockage nécessaires pour les charges de travail liées aux journaux de production.