journalctl : le mémo pour suivre et filtrer les logs Linux

journalctl en une ligne : journalctl -u <service> -f suit un service en direct, journalctl -u <service> -n 100 affiche les 100 dernières lignes, et journalctl --since "1 hour ago" montre tout ce qui est récent. De quoi couvrir 90 % des moments « pourquoi ce service ne répond plus ». Le reste de ce mémo, ce sont les patterns à copier-coller qui vous évitent de relire le man page à 2 h du matin — filtrage par unité, par temps, par priorité et par démarrage, sans oublier les commandes de nettoyage qui empêchent le journal de dévorer votre disque. Chaque commande ci-dessous fonctionne telle quelle sur toute distribution systemd (Ubuntu, Debian, Fedora, Arch).

C'est quoi journalctl, et pourquoi ne pas lire /var/log/syslog ?

Le logging à l'ancienne écrivait des fichiers texte sous /var/log — syslog, auth.log, messages. systemd a remplacé tout ça par le journal : un log binaire et indexé, géré par systemd-journald. Un simple grep ne peut pas le lire ; journalctl est la seule porte d'entrée, et en échange vous filtrez par service, par temps, par démarrage et par sévérité sans acrobaties de regex.

Le modèle mental est simple : le journal stocke tout, et journalctl est l'outil de requête. Un service n'a pas besoin de son propre fichier de log — tout ce qu'il écrit sur stdout/stderr en tournant sous systemd atterrit dans le journal automatiquement. C'est pour ça que journalctl -u nginx marche même quand vous n'avez aucune idée de l'endroit où nginx configure son log d'erreurs.

Une mise en garde : sur certaines installations minimales, le journal est volatile (stocké dans /run, effacé au reboot) parce que /var/log/journal n'existe pas. Ça se règle une fois pour toutes :

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Comment voir les 100 dernières lignes d'un log ?

-n limite la sortie aux N lignes les plus récentes (10 par défaut) :

journalctl -n 100                      # les 100 dernières lignes de tout
journalctl -u nginx -n 100             # les 100 dernières lignes d'une unité
journalctl -n 100 --no-pager           # afficher et sortir — parfait pour un pipe

--no-pager compte plus qu'il n'y paraît : sans lui, journalctl ouvre less et votre script, votre pipe ou votre one-liner ssh reste bloqué à attendre une touche. Toute commande dont la sortie part dans un pipe doit le porter.

Comment suivre les logs en direct, comme tail -f ?

Le flag -f, c'est le tail -f de journalctl — il affiche les nouvelles entrées au fil de l'eau :

journalctl -f                    # tout, en direct
journalctl -u sshd -f            # juste le démon SSH, en direct
journalctl -u ollama -f -n 50    # en direct, mais en commençant par les 50 dernières lignes

C'est la commande à lancer dans un deuxième terminal pendant que vous redémarrez un service dans le premier : systemctl restart nginx dans un panneau, journalctl -u nginx -f dans l'autre, et la cause du crash se présente généralement d'elle-même en quelques secondes. Je fais tourner exactement cette boucle sur mon homelab à chaque fois qu'un conteneur ou un service fait des siennes.

Comment afficher les logs d'un service précis ?

-u filtre par unité systemd :

journalctl -u nginx                    # une unité, tout l'historique
journalctl -u nginx -u redis           # plusieurs unités à la fois
journalctl _SYSTEMD_UNIT=nginx.service # l'alternative en correspondance exacte

Une unité peut engendrer des unités auxiliaires qui gardent la sortie intéressante — une appli web qui plante logge parfois la vraie erreur sous une autre unité. Si -u <service> ne renvoie rien alors que le service tourne visiblement, trouvez d'abord le vrai nom de l'unité :

systemctl list-units --type=service | grep -i <supposition>

Le même pattern -u marche pour les timers (systemctl list-timers donne les noms) et pour les services utilisateur — pour tout ce qui tourne sous systemd --user, ajoutez --user :

journalctl --user -u pipewire -n 50

Comment filtrer les logs par date ?

--since et --until acceptent des horodatages, mais aussi des formulations relatives très permissives :

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Combinez une fenêtre de temps et une unité, et vous avez le tri d'incident en une ligne : « qu'a loggé l'API entre 9 h et le moment où elle est tombée ? » Sur une seule machine, c'est plus rapide que n'importe quel agrégateur de logs.

Comment afficher seulement les erreurs (ou les warnings) ?

-p filtre par priorité, avec les noms de sévérité syslog :

journalctl -p err -b              # erreurs seulement, depuis ce démarrage
journalctl -p warning..alert -u nginx   # une plage de sévérités

Les priorités, par ordre décroissant : emerg, alert, crit, err, warning, notice, info, debug. Quand une machine « se comporte bizarrement », journalctl -p err -b --since today est le test de lucidité le plus rapide — il répond à « est-ce que quelque chose échoue vraiment ? » sans le bruit des lignes d'info routinières.

Comment voir les logs du démarrage précédent ?

Les services qui plantent au démarrage produisent des lignes de log avant votre boot actuel, et journalctl n'affiche par défaut que celui-ci. -b sélectionne les démarrages :

journalctl -b                 # démarrage courant uniquement
journalctl -b -1              # démarrage précédent
journalctl -b -1 -u sshd      # pourquoi SSH est mort la dernière fois
journalctl --list-boots       # index des boots stockés

C'est le flag le plus utile dans le scénario « ça a cassé, j'ai rebooté, et maintenant je ne vois plus l'erreur » — l'erreur est toujours là, un boot en arrière.

Aide-mémoire : les flags à connaître par cœur

Objectif	Commande
Suivre un service en direct	`journalctl -u <svc> -f`
Les 100 dernières lignes	`journalctl -n 100`
Depuis une heure	`journalctl --since "1 hour ago"`
Erreurs de ce boot	`journalctl -p err -b`
Boot précédent	`journalctl -b -1`
Place disque du journal	`journalctl --disk-usage`
Sortie lisible par machine	`journalctl -o json-pretty`
Messages du noyau uniquement	`journalctl -k`

Comment empêcher le journal de remplir le disque ?

On regarde ce que ça coûte, puis on plafonne :

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # garder les 500 Mo les plus récents
sudo journalctl --vacuum-time=30d      # garder les 30 derniers jours

Pour rendre le plafond permanent, mettez SystemMaxUse=500M dans la section [Journal] de /etc/systemd/journald.conf, puis sudo systemctl restart systemd-journald. Entre le plafond de taille et le filtre par boot ci-dessus, le journal redevient un outil au lieu d'une lente fuite disque.

journalctl vs dmesg vs /var/log — où regarder en premier ?

journalctl — le comportement des applications et des services. Tout ce que systemd gère est ici, indexé et filtrable. Le réflexe par défaut.
journalctl -k / dmesg — le noyau et le matériel : kills OOM, resets USB, erreurs disque. Si un processus est mort sans explication, cherchez le tueur OOM ici avant d'incriminer l'appli.
/var/log/<app>/ — uniquement pour les applis qui font leur propre logging fichier (logs d'accès nginx, PostgreSQL). Et même là, les erreurs de démarrage finissent généralement dans le journal.

Le même workflow s'étend aux services IA locaux — quand une unité ollama serve se fige, journalctl -u ollama -n 100 montre l'échec de chargement du modèle immédiatement, comme détaillé dans la comparaison Ollama vs LM Studio.

Voilà tout le mémo : -u pour l'unité, -f pour suivre, -n pour les lignes, --since pour le temps, -p pour la sévérité, -b pour les boots. Six flags couvrent à peu près toute question de log qu'une machine Linux peut vous poser.