■ space · voie prose
journalctl -u <service> -f — la commande unique qui répond à « pourquoi ce service est-il down » ; ajoutez -n 100 pour les 100 dernières lignes.
Filtrez avant de scroller: pour le temps, for time, pour les erreurs de ce boot, for errors this boot, pour le boot précédent. for the previous boot.
Plafonnez le disque une fois: sudo journalctl --vacuum-size=500M, puis SystemMaxUse=500M dans /etc/systemd/journald.conf — sinon le journal reste une lente fuite de disque.
LES SIX, EN CARTES
journalctl -u <svc> -fun tail en direct d'une unité — le second terminal pendant que vous redémarrez le service dans le premier
journalctl -n 100les 100 lignes les plus récentes ; ajoutez --no-pager pour imprimer et sortir dans un pipe
journalctl --since "1 hour ago"des fenêtres relatives tolérantes battent les horodatages exacts quand quelque chose est en panne
journalctl -p err -berreurs seulement, ce boot — le test le plus rapide de « est-ce que quelque chose échoue vraiment ? »
journalctl -b -1le boot précédent — le crash que vous avez rebooté est toujours dans le journal
journalctl --vacuum-size=500Mne garder que les 500 Mo les plus récents — une fois ; rendez-le permanent dans journald.conf
l'échelle -p, descendante — journalctl -p warning..alert prend une plage · -p err est le cheval de trait
POURQUOI PAS SIMPLEMENT LIRE /var/log/syslog ?
Le logging Linux à l'ancienne écrivait des fichiers texte sous /var/log — syslog, auth.log, messages. systemd replaced that with systemd a remplacé ça par the journal : un log binaire et indexé géré par . Plain grep cannot read it; journalctl est la seule porte d'entrée, et en échange vous obtenez le filtrage par service, temps, boot et gravité sans gymnastique regex.
Le modèle mental : le journal stocke tout, et journalctl l'interroge. Un service n'a pas besoin de son propre fichier de log — tout ce qu'il écrit sur stdout/stderr sous systemd atterrit dans le journal automatiquement. Un volatile (stocké dans /run, effacé au reboot) parce que /var/log/journal n'existe pas. Réparez une fois :
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
vérifiez : ls /var/log/journal → le répertoire existe — les boots s'accumulent au lieu d'être effacés
LIGNES, SUIVI, UNITÉS
-n limite la sortie aux N lignes les plus récentes (10 par défaut). --no-pager compte plus qu'il n'y paraît : sans lui journalctl ouvre less et votre script, pipe ou one-liner ssh se bloque en attendant une touche — toute commande que vous pipez devrait l'embarquer.
journalctl -n 100 # last 100 lines of everything
journalctl -u nginx -n 100 # last 100 lines from one unit
journalctl -n 100 --no-pager # print and exit — perfect for piping
est le is journalctl's tail -f de journalctl — il diffuse les nouvelles entrées au fil de l'eau. C'est la commande à lancer dans un second terminal pendant que vous redémarrez un service dans le premier : systemctl restart nginx dans un volet, journalctl -u nginx -f dans l'autre, et la cause du crash s'annonce d'elle-même en quelques secondes.
journalctl -f # everything, live
journalctl -u sshd -f # just the SSH daemon, live
journalctl -u ollama -f -n 50 # live, but start with the last 50 lines
filtre par unité systemd — une, plusieurs, ou l'alternative en correspondance exacte : filters by systemd unit — one, several, or the exact-match alternative:
journalctl -u nginx # one unit, all history
journalctl -u nginx -u redis # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # exact match
-u <service> ne montre rien alors que le service tourne clairement ? Les unités peuvent engendrer des unités auxiliaires qui gardent la sortie intéressante — une web app en échec logue parfois dans la systemctl list-units --type=service | grep -i <guess>. Le même schéma vaut pour les timers (systemctl list-timers affiche les noms) et pour tout ce qui tourne sous systemd --user, ajoutez --user: journalctl --user -u pipewire -n 50.
TEMPS ET GRAVITÉ
--since and --until acceptent des horodatages, mais ils acceptent aussi des formulations relatives tolérantes. Associez une fenêtre à une unité et vous avez le tri d'incident en une ligne — « qu'a fait
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
-p filtre par priorité selon l'échelle syslog montrée plus haut. Quand une machine « se comporte bizarrement », journalctl -p err -b --since today est le contrôle de bon sens le plus rapide — il répond à « est-ce que quelque chose échoue vraiment ? » sans le bruit des lignes info de routine.
journalctl -p err -b # errors only, since this boot
journalctl -p warning..alert -u nginx # a range of severities
BOOTS
Le crash que vous avez rebooté est toujours dans le journal. Les services qui plantent au démarrage produisent des lignes de log avant votre boot actuel, et journalctl ne montre silencieusement que le boot courant. -b sélectionne les boots — c'est l'option la plus utile pour « ça a cassé, j'ai rebooté, et maintenant je ne vois plus l'erreur » :
journalctl -b # current boot only
journalctl -b -1 # previous boot
journalctl -b -1 -u sshd # why SSH died last time
journalctl --list-boots # index of stored boots
LE DISQUE
Vérifiez ce que coûte le journal, puis plafonnez-le — un vacuum maintenant, une ligne de config pour toujours :
journalctl --disk-usage
sudo journalctl --vacuum-size=500M # keep newest 500 MB
sudo journalctl --vacuum-time=30d # keep newest 30 days
Pour rendre le plafond permanent, réglez SystemMaxUse=500M sous la section [Journal][Journal] dans /etc/systemd/journald.conf, puis . Entre le plafond de taille et le filtre de boot, le journal reste un outil plutôt qu'une lente fuite de disque.
08QUEL LOG D'ABORD ?
journalctl— comportement des applications et services. Tout ce que gère systemd est ici, indexé et filtrable. Premier arrêt par défaut.journalctl -k/— noyau et matériel : kills OOM, resets USB, erreurs disque. Si un processus est mort mystérieusement, cherchez le tueur OOM ici avant d'accuser l'appli.— kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.— seulement pour les applis qui font leur propre logging de fichier (logs d'accès nginx, PostgreSQL). Même alors, les erreurs de démarrage atterrissent généralement dans le journal.— only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.
Le même flux de travail s'étend aux services IA locaux — quand une unité ollama serve s'englue, journalctl -u ollama -n 100 montre immédiatement l'échec de chargement du modèle. Voilà toute la antisèche : -u pour l'unité, -f pour suivre, -n pour les lignes, --since pour le temps, -p pour la gravité, -b pour les boots. Six options couvrent presque toute question de log qu'une machine Linux vous posera — et quand la question est « pourquoi un service systemd ne démarre pas », ces
fin de l'antisèche · rien de récupéré · tout est local