Journaux systemd : journalctl en clair

Presque tout ce qui se passe sur le système finit dans le journal systemd. Un service ne démarre pas, la machine a redémarré toute seule, le site renvoie une 502 — la réponse est généralement déjà enregistrée, il suffit de savoir comment la demander.

Cinq commandes qui suffisent

journalctl -u nginx -n 50 --no-pager      # last 50 lines of one service
journalctl -u nginx -f                    # follow in real time
journalctl -p err -b                      # only errors since boot
journalctl --since "10 min ago"           # everything for the last ten minutes
journalctl -b -1 -e                       # previous boot log, end of file

La dernière est particulièrement précieuse après un redémarrage soudain : -b -1 ouvre la session précédente, et à la fin vous pouvez voir s'il s'agissait d'une panique du noyau, de l'OOM killer à l'œuvre ou d'un arrêt propre.

Les niveaux dans -p : emerg, alert, crit, err, warning, notice, info, debug. Le niveau indiqué inclut tous les niveaux plus importants.

Diagnostiquer un service en échec

systemctl status myapp
journalctl -u myapp --since today -p warning

systemctl status donne le code de sortie et les dernières lignes, journalctl donne l'image complète. Regardez :

• Main process exited, code=exited, status=1 — l'application s'est arrêtée d'elle-même sur une erreur, la cause se trouve sur la ligne au-dessus ;
• Failed to start ... Permission denied — permissions sur un fichier, un répertoire ou un port inférieur à 1024 ;
• Killed process ... (java) total-vm... de la part du noyau — l'OOM killer est intervenu, lisez Out of memory ;
• Start request repeated too quickly — le service redémarre en boucle, systemd a cessé de le lancer ; corrigez la cause et exécutez systemctl reset-failed myapp.

La liste de tout ce qui est cassé sur le système s'obtient avec systemctl --failed.

Des filtres qui font gagner du temps

journalctl --since "2026-08-22 03:00" --until "2026-08-22 04:00"
journalctl -u nginx -u php-fpm            # several services at once
journalctl _PID=1432                      # by specific process
journalctl -k                             # only kernel messages
journalctl -u sshd | grep "Failed password" | tail -20

Combinez avec grep, mais rappelez-vous : journalctl sans --no-pager ouvre un pager, quittez avec q.

Empêcher le journal de dévorer le disque

Par défaut, le journal grandit jusqu'à 10 % de la partition. Sur VDS-1 avec un disque de 40 Go, cela fait quatre gigaoctets — c'est notable.

journalctl --disk-usage
journalctl --vacuum-size=200M
journalctl --vacuum-time=14d

La limite permanente se trouve dans /etc/systemd/journald.conf :

[Journal]
SystemMaxUse=300M
MaxRetentionSec=1month

Ensuite, systemctl restart systemd-journald.

Erreurs courantes

• Lire le journal sans -u. Le flux général est encombré d'enregistrements de services, et la ligne qu'il vous faut se perd. Restreignez toujours à un service ou à un niveau.
• Perdre l'historique après un redémarrage. Si le répertoire /var/log/journal n'existe pas, le journal ne vit qu'en mémoire. Créez-le : mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal.
• Y chercher les erreurs d'application. Nginx, PostgreSQL et similaires écrivent aussi dans leurs propres fichiers dans /var/log. Si le journal est vide, vérifiez là-bas.

Lorsque le disque est plein, journalctl peut refuser de fonctionner jusqu'à ce que de l'espace soit libéré. Cette situation est traitée dans l'article Out of disk space.