Utilisation du disque de journald dans CasaOS : limiter les journaux sans interrompre la journalisation

En bref : limitez journald avant qu’il ne remplisse un petit disque système CasaOS

Le système CasaOS d’origine avait plus de 5 Go dans /var/log/journal. La solution durable n’est pas de supprimer manuellement les fichiers de journal. Définissez une limite de taille, conservez éventuellement une quantité minimale d’espace libre, puis purgez une fois les anciens journaux archivés. Ensuite, journald applique automatiquement la politique.

Mesurez le journal avant de modifier quoi que ce soit

journalctl --disk-usage
du -sh /var/log/journal 2>/dev/null
df -h /var

Si les journaux consomment plusieurs gigaoctets sur un petit disque de démarrage, déterminez la quantité d’historique récent dont vous avez réellement besoin. Pour un serveur domestique, une limite fixe est généralement plus prévisible que de laisser les valeurs par défaut consommer un pourcentage du système de fichiers.

Définissez les limites de taille et de conservation dans journald.conf

[Journal]
SystemMaxUse=1G
SystemKeepFree=1G
MaxRetentionSec=14day

SystemMaxUse limite le stockage des journaux persistants, tandis que SystemKeepFree préserve de l’espace libre pour le reste du système d’exploitation. MaxRetentionSec est facultatif si vous souhaitez également définir une limite temporelle. Les limites de taille de journald définissent l’interaction entre ces limites.

Purgez une fois les anciens journaux après avoir défini la politique

sudo journalctl --rotate
sudo journalctl --vacuum-size=1G

La purge supprime les fichiers de journal archivés ; elle ne remplace pas la configuration. Si vous effectuez uniquement une purge sans jamais définir de limite, le répertoire peut à nouveau grossir. Les commandes de purge de journalctl couvrent les commandes de nettoyage prises en charge.

N’arrêtez pas journald simplement pour remplacer le fichier de configuration

L’article de 2024 arrêtait le service, supprimait la configuration et copiait un fichier de remplacement. Cela fonctionnait, mais était plus perturbateur que nécessaire. Modifiez le fichier en toute sécurité, conservez une sauvegarde, puis redémarrez le service :

sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
sudo nano /etc/systemd/journald.conf
sudo systemctl restart systemd-journald

journald peut-il stocker les journaux sur un autre disque ?

Pas via un simple chemin arbitraire dans journald.conf. Storage=persistent cible /var/log/journal; Storage=volatile utilise /run/log/journal. Si vous avez besoin d’une conservation plus longue ailleurs, transférez les journaux vers un autre hôte syslog/journal au lieu de monter à la légère des chemins système critiques.

Identifier le service qui crée trop de journaux

journalctl -p warning..alert --since "24 hours ago"
journalctl --since "24 hours ago" | tail -200
systemctl --failed

Une limite de disque protège le système d’exploitation, mais elle ne résout pas le problème d’un service qui consigne la même erreur des milliers de fois. Corrigez le service trop bavard une fois que le système dispose d’une marge suffisante.

Si vous envisagez de passer d’une ancienne installation de CasaOS à un serveur davantage conçu comme un appliance, la plateforme ZimaBoard 2 et la sauvegarde ZimaOS offrent un contexte de migration plus sûr.

Empêcher un service de saturer le journal

Si un conteneur ou un démon émet en continu le même avertissement, les limites globales de stockage ne font que contenir les dégâts. Identifiez les unités les plus bavardes, puis corrigez la source :

journalctl --since "1 hour ago" -o short-unix | tail -500
journalctl -u SERVICE_NAME --since "1 hour ago"

Pour les services gérés par systemd, les contrôles du débit des journaux par unité peuvent réduire les pics sans supprimer tous les autres journaux système. N’utilisez la limitation du débit qu’après avoir compris ce qui sera supprimé ; des erreurs répétées de stockage, de système de fichiers ou de réseau peuvent constituer les indices nécessaires pour résoudre le problème sous-jacent.

FAQ

Quelle valeur donner à SystemMaxUse ?

Il n’existe pas de valeur universelle. Sur un petit disque système, 500 Mo à 2 Go constitue une plage de départ pratique si vous avez rarement besoin d’un historique détaillé. Gardez suffisamment d’espace libre pour les mises à jour et les métadonnées des applications.

La commande journalctl --vacuum-size supprime-t-elle les journaux actuels ?

Il supprime les fichiers journaux archivés jusqu’à ce que la taille cible soit presque atteinte. Effectuez d’abord une rotation si vous souhaitez déplacer le journal actif dans l’ensemble des journaux archivés.

Dois-je utiliser logrotate pour /var/log/journal ?

Non. Les fichiers journaux binaires sont gérés directement par systemd-journald. Utilisez les paramètres de taille et de conservation de journald ainsi que les opérations de nettoyage de journalctl.

Puis-je conserver les journaux sur un autre disque dur ?

Oui, via la redirection des journaux ou un point de montage conçu à cet effet, mais journald ne permet pas de définir arbitrairement un chemin personnalisé. La journalisation distante est généralement plus sûre que le déplacement d’un répertoire système essentiel.

Pourquoi le journal a-t-il atteint plusieurs gigaoctets ?

La politique par défaut peut autoriser un volume de stockage important, et un service trop bavard peut générer rapidement des entrées. Vérifiez à la fois la limite configurée et le service à l’origine du volume.