Linux sans magie #19 — journalctl : retrouver les bons logs d’un service sans fouiller partout

Dans l’article précédent, nous avons appris à utiliser systemctl pour observer et piloter un service. Mais lorsqu’un service démarre mal, se coupe, redémarre en boucle ou refuse une configuration, son état ne suffit pas toujours à expliquer la cause.

C’est là qu’intervient journalctl.

Sur un système utilisant systemd, de nombreux messages produits par le système et les services sont collectés par le journal. journalctl permet de les consulter sans parcourir au hasard plusieurs fichiers sous /var/log.

L’objectif de cet article n’est pas d’explorer toutes les possibilités du journal systemd. Il est d’acquérir une méthode simple : partir du service concerné, réduire progressivement le bruit, puis observer les événements utiles.

Contexte et problème

Une commande comme :

systemctl status <unite>

affiche déjà quelques lignes récentes du journal. C’est utile pour un premier diagnostic, mais cette vue reste volontairement limitée.

Dès qu’il faut répondre à des questions comme :

que s’est-il passé juste avant l’échec ?
le problème existait-il déjà au boot précédent ?
quels messages appartiennent réellement à ce service ?
que s’est-il passé pendant les dix dernières minutes ?
de nouveaux messages apparaissent-ils pendant que je reproduis le problème ?

il faut interroger directement le journal.

Le mauvais réflexe consiste à lancer :

journalctl

puis à faire défiler des milliers de lignes.

Le bon réflexe consiste à filtrer dès le départ.

Comprendre ce que lit `journalctl`

journalctl interroge le journal géré par systemd-journald.

Le journal ne se limite pas à une suite de lignes anonymes. Les entrées contiennent des métadonnées permettant notamment de relier un message à une unité systemd, un processus, un identifiant de boot ou un niveau de priorité.

C’est ce qui permet à journalctl d’effectuer des recherches beaucoup plus ciblées qu’un simple affichage intégral d’un fichier texte.

Pour diagnostiquer un service système, le filtre le plus utile est généralement l’unité.

Filtrer par service avec `-u`

Pour afficher les messages associés à une unité système :

journalctl -u <unite>

Exemple :

journalctl -u ssh.service

Le nom exact de l’unité dépend de la distribution et de la machine. Comme dans l’article #18, commencez par identifier l’unité réellement présente au lieu de recopier arbitrairement un nom d’exemple.

Cette commande change complètement la logique du diagnostic : au lieu de chercher le nom du programme dans tous les journaux, on demande directement les entrées liées à l’unité.

Pour un service utilisateur géré par le systemd de votre session, l’équivalent est :

journalctl --user-unit=<unite>

Nous utiliserons cette variante dans le lab afin d’éviter de manipuler un service système réel.

Réduire la période observée

Même après avoir filtré par unité, l’historique peut rester volumineux.

Le boot courant avec `-b`

Pour limiter la recherche au démarrage courant :

journalctl -b -u <unite>

Cela répond à une question fréquente : que s’est-il passé depuis le dernier boot ?

Il est également possible de consulter d’autres boots enregistrés. L’objectif ici n’est pas de détailler toute la gestion de l’historique, mais de retenir que le journal peut distinguer les démarrages du système lorsque les données correspondantes sont disponibles.

Une fenêtre temporelle avec `--since` et `--until`

Pour ne lire que les messages récents :

journalctl -u <unite> --since "10 minutes ago"

Ou avec une période bornée :

journalctl -u <unite> --since "2026-09-14 14:00" --until "2026-09-14 14:15"

Les dates ci-dessus ne sont qu’un exemple de syntaxe. Sur un incident réel, choisissez une fenêtre correspondant au moment du problème.

La documentation systemd prévoit explicitement --since= et --until= pour filtrer les entrées selon leur horodatage.

Limiter le nombre de lignes avec `-n`

Quand on veut simplement voir les derniers événements :

journalctl -u <unite> -n 20

Cela évite d’afficher tout l’historique pour ne lire que les vingt entrées les plus récentes correspondant au filtre.

Vous pouvez combiner les critères :

journalctl -b -u <unite> -n 50

La méthode devient alors :

une unité précise
→ le boot courant
→ seulement les dernières lignes utiles

Ce type de combinaison est souvent plus efficace qu’une recherche globale.

Suivre les nouveaux messages avec `-f`

Lorsqu’un problème peut être reproduit, il est utile de regarder les événements au moment où ils apparaissent.

journalctl -u <unite> -f

L’option -f suit les nouvelles entrées au fur et à mesure, dans un fonctionnement comparable à un suivi en direct.

Une méthode classique consiste à ouvrir deux terminaux :

Terminal 1 : journalctl -u <unite> -f
Terminal 2 : reproduire l'action ou le problème

On observe alors immédiatement les messages générés par l’unité pendant le test.

Pour quitter le suivi, utilisez Ctrl+C.

Sur un système de production, reproduire volontairement un défaut peut avoir un impact. Le suivi du journal est non destructif, mais l’action testée ne l’est pas forcément. Il faut donc séparer observer et provoquer.

Filtrer par priorité avec `-p`

Les messages du journal possèdent un niveau de priorité compatible avec les niveaux syslog.

Par exemple :

journalctl -u <unite> -p err

permet de limiter l’affichage aux messages correspondant au niveau demandé et aux niveaux plus prioritaires selon les règles de filtrage de journalctl.

Ce filtre peut être utile pour réduire rapidement le bruit, mais il ne faut pas en faire une règle absolue.

Un message warning ou même info peut fournir le contexte nécessaire à la compréhension d’une erreur. Commencez donc généralement par l’unité et la période, puis utilisez la priorité si le volume reste trop important.

`--no-pager` : pratique pour un résultat court ou automatisé

Par défaut, journalctl peut utiliser un pager lorsque la sortie est destinée à un terminal.

Pour afficher directement le résultat :

journalctl -u <unite> -n 20 --no-pager

Cette forme est particulièrement pratique dans une procédure, un copier-coller de diagnostic ou un script qui ne doit pas ouvrir une interface interactive.

Évitez toutefois de traiter la sortie humaine par des expressions fragiles si vous avez besoin d’un format structuré. journalctl propose plusieurs modes de sortie, mais leur usage avancé dépasse le périmètre de cet article.

Prérequis

Le lab utilise une unité utilisateur transitoire, comme dans l’article #18, afin de générer quelques messages sans modifier un service système réel.

Prérequis :

une distribution utilisant systemd ;
une session utilisateur avec un gestionnaire systemd utilisateur actif ;
les commandes systemd-run, systemctl, journalctl et sh.

Vérifiez :

command -v systemd-run
command -v systemctl
command -v journalctl
command -v sh

Si votre environnement ne dispose pas d’un gestionnaire systemd utilisateur fonctionnel, réalisez le lab sur une VM ou une session Linux adaptée au lieu de remplacer arbitrairement les commandes par des opérations sur un service système réel.

Mise en pratique

1. Créer un service utilisateur qui écrit quelques messages

Exécutez :

systemd-run --user --unit=linux-sans-magie-journal-demo /bin/sh -c 'echo "demo: démarrage"; sleep 1; echo "demo: traitement"; sleep 1; echo "demo: fin"'

Cette commande crée une unité transitoire utilisateur et exécute un petit shell qui écrit trois messages sur sa sortie standard.

Aucun fichier d’unité permanent n’est créé et aucun sudo n’est nécessaire.

2. Vérifier l’état du service

systemctl --user status linux-sans-magie-journal-demo.service --no-pager

Comme la commande se termine rapidement, l’unité peut déjà être inactive au moment où vous consultez son état. Ce n’est pas un échec : le but du lab est précisément de retrouver ce qu’elle a écrit dans le journal après son exécution.

3. Lire uniquement les logs de cette unité utilisateur

journalctl --user-unit=linux-sans-magie-journal-demo.service --no-pager

Vous devez retrouver les trois messages du lab parmi les entrées associées à l’unité.

Le rendu exact contient aussi des métadonnées et peut varier selon la version de systemd, mais les messages doivent permettre d’identifier :

demo: démarrage
demo: traitement
demo: fin

4. Afficher seulement les dernières lignes

journalctl --user-unit=linux-sans-magie-journal-demo.service -n 5 --no-pager

Le journal ne relit plus inutilement tout l’historique correspondant à l’unité.

5. Filtrer sur une période récente

journalctl --user-unit=linux-sans-magie-journal-demo.service --since "5 minutes ago" --no-pager

Si vous venez d’exécuter le lab, les messages doivent toujours être visibles.

Cette étape illustre un réflexe essentiel lors d’un incident : si vous connaissez approximativement l’heure du problème, utilisez cette information pour réduire immédiatement la recherche.

6. Tester le suivi en direct

Dans un premier terminal :

journalctl --user-unit=linux-sans-magie-journal-demo.service -f

Dans un second terminal, relancez :

systemd-run --user --unit=linux-sans-magie-journal-demo-2 /bin/sh -c 'echo "demo2: démarrage"; sleep 1; echo "demo2: fin"'

Attention : le premier terminal filtre encore linux-sans-magie-journal-demo.service, donc les messages de linux-sans-magie-journal-demo-2.service ne doivent pas apparaître.

C’est volontaire. Cette absence montre que le filtre par unité fonctionne.

Quittez avec Ctrl+C, puis lancez :

journalctl --user-unit=linux-sans-magie-journal-demo-2.service -n 10 --no-pager

Vous devez alors retrouver les messages du second service.

Vérification

Le lab est réussi si vous êtes capable d’expliquer cette progression :

je connais le service concerné
        ↓
je filtre par unité
        ↓
je réduis la période
        ↓
je limite le nombre de lignes si nécessaire
        ↓
je suis en direct uniquement si je dois reproduire le problème

Le point important n’est pas de mémoriser toutes les options de journalctl. Il est d’éviter la recherche globale quand vous disposez déjà d’informations permettant de filtrer.

Bonnes pratiques

Commencez souvent par :

systemctl status <unite>

puis passez à :

journalctl -u <unite>

si les quelques lignes de status ne suffisent pas.

Ajoutez ensuite les filtres en fonction de ce que vous savez :

journalctl -b -u <unite> --since "15 minutes ago" -n 100 --no-pager

Ne cherchez pas à utiliser toutes les options en même temps. Chaque filtre doit répondre à une question concrète.

Notez également l’heure d’un incident avant de redémarrer un service. Un redémarrage peut modifier le contexte observable ; connaître la fenêtre temporelle facilite ensuite l’analyse.

Enfin, distinguez toujours :

état du service → systemctl
historique des événements → journalctl

Les deux outils se complètent.

Sécurité

Lire le journal est une opération d’observation, mais toutes les entrées ne sont pas nécessairement accessibles à tous les utilisateurs. Selon la distribution, les groupes, les ACL et la configuration du système, certains journaux système peuvent nécessiter des droits supplémentaires.

N’utilisez pas automatiquement sudo journalctl ... simplement pour contourner un refus. Vérifiez d’abord si vous avez réellement besoin d’accéder à des journaux système sensibles et si votre compte doit disposer de ce niveau d’accès.

Les logs peuvent aussi contenir des informations sensibles : chemins internes, noms d’hôtes, identifiants, adresses IP, paramètres ou extraits de requêtes. Avant de copier un journal dans un ticket, un dépôt ou un outil externe, relisez et expurgez les données qui ne doivent pas être partagées.

Coûts

Le lab ne nécessite aucune ressource payante.

Il peut être exécuté sur une machine Linux ou une VM de laboratoire disposant de systemd. Si une VM cloud temporaire est utilisée, son coût dépend du fournisseur et de sa durée d’exécution.

Limites et points de vigilance

Cet article ne couvre pas en profondeur :

la configuration de systemd-journald ;
la persistance ou la rotation du journal ;
journalctl --vacuum-* ;
les formats JSON ou export ;
les filtres avancés par champs ;
les journaux du noyau avec -k ;
l’analyse des boots historiques en détail ;
la centralisation vers une plateforme de logs externe.

Il ne faut pas non plus supposer que tous les logs d’une application passent nécessairement par le journal systemd. Certaines applications écrivent encore dans leurs propres fichiers, dans syslog ou vers une plateforme externe selon leur configuration.

journalctl est donc un excellent point de départ pour les services systemd, mais pas une garantie que toute information applicative se trouve au même endroit.

Rollback ou nettoyage

Les deux unités du lab sont transitoires et se terminent d’elles-mêmes.

Vous pouvez vérifier leur état :

systemctl --user is-active linux-sans-magie-journal-demo.service
systemctl --user is-active linux-sans-magie-journal-demo-2.service

Le résultat attendu après leur terminaison est un état inactif.

Aucun fichier permanent n’a été ajouté à /etc/systemd/system ou ~/.config/systemd/user.

Les entrées déjà écrites dans le journal ne sont pas supprimées par ce nettoyage. Leur conservation dépend de la politique du journal de votre système. Il n’est pas nécessaire de modifier cette politique pour réaliser le lab.

Références officielles

journalctl — Query the systemd journal — systemd upstream
systemd-journald.service — Journal service — systemd upstream
systemctl — Control the systemd system and service manager — systemd upstream

Conclusion

journalctl devient beaucoup plus simple lorsqu’on arrête de le considérer comme un énorme fichier de logs à parcourir.

Pour diagnostiquer un service, commencez par son unité. Réduisez ensuite la période observée, limitez le volume si nécessaire et utilisez le suivi en direct uniquement lorsque vous avez besoin d’observer un événement au moment où il se produit.

Le raisonnement à retenir est :

identifier le service
→ filtrer son journal
→ réduire la période
→ lire le contexte utile
→ reproduire seulement si nécessaire

Avec systemctl pour l’état et journalctl pour l’historique, vous disposez déjà des deux outils fondamentaux pour diagnostiquer un grand nombre de problèmes de services systemd sans fouiller partout dans le système.