Maîtriser les journaux système avec journalctl sous Linux

journalctl est la commande pour consulter les logs système sur toute distribution utilisant systemd. Elle remplace la lecture manuelle des fichiers dans /var/log/ en offrant un journal structuré, filtrable par service, par priorité, par date et par boot. C'est l'outil de diagnostic principal de l'administrateur Linux.

Ce que vous allez apprendre

• Consulter les logs système et les logs d'un service spécifique
• Filtrer les logs par date, priorité et boot
• Suivre les logs en temps réel avec -f
• Configurer la rétention et la taille maximale du journal
• Gérer les permissions d'accès aux logs
• Utiliser les formats de sortie avancés

Dans quel contexte ?

journalctl intervient dans toutes les situations de diagnostic :

• Un service refuse de démarrer, les logs expliquent l'erreur
• Le système a redémarré de façon inattendue, consulter les boots précédents
• Une application produit des erreurs intermittentes, filtrer par priorité
• L'espace disque est consommé par les logs, vérifier et configurer la rétention
• Un problème de sécurité nécessite d'analyser les connexions récentes

LFCS / RHCSA

La consultation des journaux avec journalctl est un objectif des deux certifications. Vous devez savoir filtrer par service, par priorité, par date et configurer la persistance du journal.

Le journal systemd

journald (systemd-journald) collecte les logs de trois sources :

Source	Contenu
Messages du noyau	Équivalent de dmesg
Syslog	Messages des services via la socket /dev/log
stdout/stderr	Sorties des services gérés par systemd

Glissez pour voir

Le journal est stocké sous forme binaire dans /var/log/journal/ (persistant) ou /run/log/journal/ (volatile, perdu au reboot).

# Vérifier l'espace utilisé par le journal
journalctl --disk-usage

Archived and active journals take up 632.5M in the file system.

Persistance du journal

Sous le réglage par défaut Storage=auto, le journal devient persistant dès que /var/log/journal/ existe :

# Vérifier que le répertoire existe
ls -ld /var/log/journal/

Si le répertoire n'existe pas, le journal est volatil (perdu au reboot). Pour activer la persistance, il faut quatre gestes, et le dernier est celui qu'on oublie :

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
sudo journalctl --flush

Sans `journalctl --flush`, rien ne bouge

C'est l'étape manquante de presque toutes les recettes qu'on trouve en ligne. Après les trois premières commandes seulement, mesuré sur AlmaLinux 10 :

sudo find /var/log/journal -type f | wc -l

0

Le répertoire est là, vide, et le service annonce toujours Runtime Journal (/run/log/journal/...). C'est journalctl --flush qui demande à journald de basculer et de recopier le journal volatil sur le disque. Aussitôt après, les fichiers apparaissent et journalctl --header montre un File path sous /var/log/journal/.

Autre précision utile : systemd-tmpfiles --create --prefix /var/log/journal ne crée pas le répertoire, contrairement à ce que son nom laisse croire. La règle qui le concerne dans /usr/lib/tmpfiles.d/journal-nocow.conf est un h, qui pose un attribut de fichier, pas un d qui créerait le répertoire. Le mkdir -p n'est donc pas facultatif.

Configurer explicitement la persistance

La règle « le répertoire existe donc le journal est persistant » ne vaut que sous Storage=auto. Avec Storage=volatile, le journal repart en mémoire malgré la présence de /var/log/journal/. Les trois valeurs se comportent différemment :

Storage=	Comportement
auto (défaut)	Persistant si /var/log/journal/ existe, volatil sinon
persistent	Persistant, le répertoire est créé au besoin
volatile	Toujours en mémoire, même si le répertoire existe

Glissez pour voir

Pour ne pas dépendre de l'existence d'un répertoire, posez explicitement Storage=persistent (voir la section Configuration).

Consulter les logs

Sans aucun filtre, journalctl déverse la totalité du journal conservé, de l'entrée la plus ancienne à la plus récente, dans un pager (less) que l'on quitte avec q. Les options qui suivent servent à réduire ce flux à ce qui vous intéresse : un démarrage précis, une unité systemd, une fenêtre horaire. Elles se cumulent dans une même commande, chaque option ajoutée restreint un peu plus le résultat.

Logs du dernier boot

journald numérote les démarrages du système : 0 désigne le boot en cours, -1 le précédent, et ainsi de suite vers le passé. L'option -b limite l'affichage à un démarrage donné, ce qui isole les messages d'un incident sans remonter tout l'historique. --list-boots affiche les démarrages conservés avec leur identifiant et leur plage horaire ; si cette liste ne contient qu'une seule ligne, le journal n'est pas persistant.

# Tous les logs depuis le dernier démarrage
journalctl -b

# Logs du boot précédent
journalctl -b -1

# Lister les boots disponibles
journalctl --list-boots

-2 abc123... Thu 2026-06-26 08:14:21 CEST - Thu 2026-06-26 22:30:05 CEST
-1 def456... Fri 2026-06-27 07:45:12 CEST - Fri 2026-06-27 23:15:33 CEST
 0 ghi789... Sat 2026-06-28 06:32:15 CEST - Sat 2026-06-28 12:50:14 CEST

Logs d'un service

L'option -u filtre sur une unité systemd, c'est-à-dire le nom du service tel que systemd le connaît (nginx.service, que l'on peut abréger en nginx). Répéter -u cumule plusieurs unités et affiche leurs messages entrelacés dans l'ordre chronologique, ce qui aide à corréler un serveur web et sa base de données pendant le même incident. Si la sortie affiche No entries, le nom de l'unité est presque toujours en cause.

# Logs de nginx
journalctl -u nginx

# Logs de nginx depuis le dernier boot
journalctl -u nginx -b

# Logs de plusieurs services
journalctl -u nginx -u postgresql

Suivre les logs en temps réel

L'option -f (follow) ne rend pas la main : elle affiche les nouvelles entrées au fur et à mesure que les services les écrivent, jusqu'à Ctrl+C. C'est le mode à lancer dans un second terminal avant de redémarrer un service, pour voir l'erreur au moment précis où elle se produit. Les options se combinent, -fu nginx suit un seul service en direct.

# Équivalent de tail -f
journalctl -f

# Suivre un service spécifique
journalctl -fu nginx

Filtrer par date

--since et --until bornent la recherche dans le temps. Elles acceptent une date absolue au format AAAA-MM-JJ HH:MM comme une expression relative en anglais (1 hour ago, 30 min ago, yesterday, today), interprétée par rapport à l'heure courante de la machine. Si vous omettez --until, la borne haute est l'instant présent. C'est le moyen le plus rapide de cadrer un incident dont vous connaissez l'heure approximative.

# Depuis une date
journalctl --since "2026-06-28 08:00"

# Jusqu'à une date
journalctl --until "2026-06-28 12:00"

# Combiné
journalctl --since "1 hour ago"

# Les 30 dernières minutes
journalctl --since "30 min ago"

# Hier
journalctl --since yesterday --until today

Filtrer par priorité

Le journal utilise les niveaux de priorité syslog (0 = le plus critique, 7 = le plus verbeux) :

Niveau	Nom	Signification
0	emerg	Système inutilisable
1	alert	Action immédiate requise
2	crit	Erreur critique
3	err	Erreur
4	warning	Avertissement
5	notice	Normal mais significatif
6	info	Information
7	debug	Debug (très verbeux)

Glissez pour voir

# Erreurs et au-dessus (0 à 3)
journalctl -p err

# Erreurs depuis le dernier boot
journalctl -p err -b

# Avertissements et au-dessus pour un service
journalctl -u nginx -p warning

Priorité en diagnostic

En cas de problème, commencez par -p err -b pour voir uniquement les erreurs du boot actuel. Si rien n'apparaît, élargissez à -p warning.

Rechercher dans les logs

--grep applique une expression régulière au champ MESSAGE des entrées, sans passer par un tube vers la commande grep. Le filtrage se fait pendant la lecture du journal binaire, donc plus vite, et les métadonnées de chaque entrée restent exploitables. La recherche est sensible à la casse dès que le motif contient une majuscule, et insensible sinon ; --case-sensitive=no force le comportement insensible dans tous les cas.

# Recherche textuelle (grep intégré)
journalctl -b --grep "error|fail"

# Recherche insensible à la casse
journalctl -b --grep "timeout" --case-sensitive=no

Logs du noyau

L'option -k (alias --dmesg) restreint l'affichage aux messages émis par le noyau : détection du matériel au démarrage, erreurs de périphérique, manque de mémoire, paquets rejetés par le pare-feu. Là où dmesg numérote ses lignes en secondes écoulées depuis le boot, journalctl les horodate avec la date et l'heure réelles, ce qui permet de les recouper avec les logs applicatifs. Ajouter -b cible le démarrage en cours, indispensable après un incident matériel.

# Équivalent de dmesg avec horodatage
journalctl -k

# Messages noyau du boot actuel
journalctl -k -b

Formats de sortie

journalctl propose plusieurs formats avec l'option -o :

Format	Usage
short	Format par défaut (similaire à syslog)
short-precise	Avec microsecondes
verbose	Tous les champs structurés
json	JSON (pour parsing automatisé)
json-pretty	JSON indenté (lecture humaine)
cat	Uniquement le message (sans métadonnées)

Glissez pour voir

# Format verbeux (tous les champs)
journalctl -u nginx -n 1 -o verbose

Sat 2026-06-28 06:32:15.123456 CEST [s=abc123;i=1;b=def456;m=789...]
    _TRANSPORT=syslog
    _UID=0
    _GID=0
    _SYSTEMD_UNIT=nginx.service
    MESSAGE=Starting A high performance web server...
    PRIORITY=6
    SYSLOG_FACILITY=3

# Format JSON pour un outil de centralisation
journalctl -u nginx -n 5 -o json

Centralisation des logs

Le format JSON facilite l'envoi des logs vers des solutions de centralisation comme Loki, Elasticsearch ou Graylog. Utilisez journalctl -o json combiné à un agent de collecte.

Configuration de journald

Le fichier livré par la distribution est /usr/lib/systemd/journald.conf. Sur AlmaLinux 10 et RHEL 10, /etc/systemd/journald.conf n'existe pas : il ne faut donc pas l'éditer, mais déposer un drop-in.

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/99-retention.conf

Créer /etc/systemd/journald.conf masque tous les défauts

Ouvrir directement /etc/systemd/journald.conf avec un éditeur sur une distribution qui ne le fournit pas crée un fichier vierge. Ce fichier vide prend alors la priorité sur celui de /usr/lib/, et toutes les valeurs par défaut documentées disparaissent silencieusement. Le comportement du journal change sans qu'une seule option ait été écrite.

Un drop-in sous /etc/systemd/journald.conf.d/ ne présente pas ce risque : il ne surcharge que les options qu'il déclare, et le reste continue de venir du fichier de la distribution. Pour voir la configuration effective, toutes couches confondues :

sudo systemd-analyze cat-config systemd/journald.conf

Options essentielles

Le fichier suit le format INI : la section [Journal] en tête, puis une option par ligne. Une ligne commentée avec # n'est pas neutre au sens strict, elle laisse simplement l'option à sa valeur par défaut compilée dans systemd. Les réglages ci-dessous couvrent les quatre décisions à prendre sur un serveur : où stocker le journal, quelle taille lui accorder, combien de temps le conserver, et à quel rythme accepter les messages d'un service bavard.

[Journal]
# Persistance du journal (persistent, volatile, auto, none)
Storage=persistent

# Taille maximale du journal
SystemMaxUse=500M

# Taille maximale par fichier
SystemMaxFileSize=50M

# Durée maximale de rétention
MaxRetentionSec=3month

# Compression des anciens fichiers
Compress=yes

# Taux de limitation (messages par intervalle par service)
RateLimitIntervalSec=30s
RateLimitBurst=10000

Option	Effet
Storage=persistent	Le journal survit aux reboots
SystemMaxUse	Taille totale maximale du journal
SystemMaxFileSize	Taille maximale de chaque fichier journal
MaxRetentionSec	Durée maximale de conservation
RateLimitBurst	Nombre max de messages par intervalle (par service)

Glissez pour voir

Après modification, restart et pas reload :

sudo systemctl restart systemd-journald

systemd-journald ne sait pas se recharger à chaud, et le dit :

Failed to reload systemd-journald.service: Job type reload is not applicable
for unit systemd-journald.service.

Une faute de frappe dans la configuration ne se voit qu'au redémarrage du service

Ni l'éditeur, ni systemd-analyze cat-config ne valident ce que vous écrivez. cat-config affiche sans broncher une clé mal orthographiée et sort en 0.

C'est le restart qui révèle le problème, et uniquement dans le journal :

sudo journalctl -u systemd-journald --since "1 min ago"

/etc/systemd/journald.conf.d/98-test.conf:2: Unknown key 'Compresss' in section
[Journal], ignoring.
/etc/systemd/journald.conf.d/98-test.conf:3: Failed to parse
Storage=persistant, ignoring: Invalid argument

Notez le second message : persistant avec un a au lieu de persistent est ignoré, et le journal retombe sur son comportement par défaut. Prenez le réflexe de relire le journal du service juste après chaque restart.

SystemKeepFree peut annuler votre SystemMaxUse

Le piège classique de cette section : SystemMaxUse fixe un plafond, mais SystemKeepFree réserve une quantité d'espace libre sur le système de fichiers, et c'est la contrainte la plus stricte des deux qui gagne.

Mesuré sur une racine offrant 16 434 Mo libres, avec SystemMaxUse=200M et SystemKeepFree=16500M :

System Journal (/var/log/journal/4a8981f6...) is 16M, max 16M, 0B free.

Le plafond effectif tombe à 16 Mo, alors que la configuration en demandait 200. Sans la ligne SystemKeepFree, la même machine annonce max 1.8G. Si votre journal reste obstinément minuscule, c'est la première chose à vérifier.

Rate limiting

Si un service écrit trop de logs trop vite, journald en supprime. Le message Suppressed N messages apparaît dans les logs. Augmentez RateLimitBurst si c'est un comportement légitime, ou corrigez le service trop bavard.

Nettoyage du journal

Les options --vacuum-* suppriment des fichiers journaux archivés, jamais le fichier actif en cours d'écriture. Le nettoyage est donc immédiat mais partiel : si un seul gros fichier actif occupe la place, forcez d'abord une rotation avec journalctl --rotate. Ces commandes exigent les droits root et n'ont aucun effet durable, le journal se remettra à grossir tant que SystemMaxUse n'est pas fixé dans la configuration.

Réduire par taille

--vacuum-size supprime les fichiers archivés les plus anciens jusqu'à ce que le journal occupe au plus la taille demandée. La commande énumère chaque fichier supprimé puis annonce l'espace libéré, ce qui vous laisse une trace de ce que vous venez de perdre définitivement.

# Réduire le journal à 200 Mo
sudo journalctl --vacuum-size=200M

Réduire par ancienneté

--vacuum-time raisonne sur la date des entrées et non sur le volume : tout fichier archivé dont la dernière entrée est plus ancienne que le délai indiqué est supprimé. Les unités acceptées vont de la seconde à l'année (s, m, h, days, weeks, months, years). C'est la variante à privilégier quand une politique de rétention vous impose une durée de conservation plutôt qu'une taille.

# Supprimer les logs de plus de 2 semaines
sudo journalctl --vacuum-time=2weeks

Réduire par nombre de fichiers

--vacuum-files ne garde que les N fichiers journaux les plus récents, sans considérer ni leur taille ni leur âge. Ce critère n'a de sens que si les fichiers ont une taille homogène, donc si SystemMaxFileSize est fixé. Les trois options --vacuum-* peuvent figurer dans la même commande, la contrainte la plus stricte l'emporte.

# Garder uniquement les 5 derniers fichiers
sudo journalctl --vacuum-files=5

# Vérifier l'espace après nettoyage
journalctl --disk-usage

Permissions

Par défaut, seuls root et les membres du groupe systemd-journal peuvent lire le journal complet :

# Ajouter un utilisateur au groupe
sudo usermod -aG systemd-journal mon-utilisateur

Les utilisateurs non privilégiés ne voient que les logs de leurs propres services (timers/services utilisateur).

Journal et sécurité

Deux réglages de journald.conf concernent l'exploitation du journal en contexte d'audit. Le premier rend détectable toute modification du journal après coup, y compris par un attaquant qui aurait obtenu les droits root. Le second permet de continuer à alimenter une chaîne syslog existante, par exemple pour expédier les messages vers un collecteur distant que l'attaquant ne contrôle pas.

Vérifier l'intégrité

journald peut sceller (seal) les fichiers pour détecter toute altération :

/etc/systemd/journald.conf

[Journal]
Seal=yes

Forward vers syslog

Pour utiliser journald en parallèle d'un serveur syslog traditionnel (rsyslog, syslog-ng) :

[Journal]
ForwardToSyslog=yes

Dépannage

Les symptômes ci-dessous couvrent la quasi-totalité des blocages rencontrés sur le journal : plus rien après un redémarrage, service introuvable, messages supprimés, disque saturé. Lisez la colonne Cause probable avant d'appliquer la solution, plusieurs symptômes se ressemblent sans avoir la même origine. Deux commandes tranchent la plupart des cas : journalctl --list-boots pour savoir si le journal est persistant, et systemctl status systemd-journald pour vérifier que le démon tourne.

Symptôme	Cause probable	Solution
Journal vide après reboot	Persistance non configurée	Créer /var/log/journal/, Storage=persistent, puis journalctl --flush
/var/log/journal/ existe mais le journal reste volatil	journalctl --flush oublié, ou Storage=volatile	Lancer --flush ; vérifier systemd-analyze cat-config systemd/journald.conf
Journal plafonné bien en dessous de SystemMaxUse	SystemKeepFree réserve plus d'espace libre que disponible	Lire la ligne is …, max …, … free au démarrage du service
Réglage sans effet, aucune erreur visible	Clé mal orthographiée, ignorée en silence	journalctl -u systemd-journald juste après le restart
No entries pour un service	Mauvais nom d'unité	Vérifier avec systemctl list-units | grep nom
Suppressed N messages	Rate limiting actif	Augmenter RateLimitBurst ou corriger le service
Journal trop volumineux	Pas de limite configurée	Configurer SystemMaxUse et MaxRetentionSec
Utilisateur ne voit pas les logs	Pas dans le groupe	sudo usermod -aG systemd-journal user
Logs des boots précédents absents	Journal volatil	Activer Storage=persistent

Glissez pour voir

# Diagnostic rapide
journalctl --disk-usage                    # Espace utilisé
journalctl --list-boots                     # Boots disponibles
journalctl -p err -b                        # Erreurs du boot actuel
systemctl status systemd-journald           # État du démon

Bonnes pratiques

Ces réflexes évitent les deux ennuis les plus fréquents avec journald : un journal vidé au redémarrage juste au moment où vous en aviez besoin, et une partition /var saturée par des logs sans limite. Ils se posent à l'installation du serveur, pas pendant l'incident, car aucun de ces réglages ne reconstruit rétroactivement les entrées déjà perdues.

• Toujours activer la persistance : sans /var/log/journal/, les logs sont perdus au reboot
• Configurer SystemMaxUse : éviter que le journal remplisse le disque (200-500 Mo est un bon compromis)
• Configurer MaxRetentionSec, 1 à 3 mois selon les besoins de conformité
• Commencer le diagnostic par journalctl -p err -b : les erreurs du boot actuel sont le point de départ
• Utiliser -u service pour cibler un service, ne pas parcourir tout le journal
• Planifier le nettoyage, journalctl --vacuum-size ou --vacuum-time régulièrement
• Centraliser les logs en production, journald seul ne suffit pas pour un audit ou une corrélation multi-serveurs

Mettre en pratique

Un journal qui disparaît au reboot, cela ne se constate qu'en redémarrant vraiment. Ce lab vous confie une VM au journal volatil : vous activez Storage=persistent, créez /var/log/journal/ et prouvez après un redémarrage que les boots précédents restent lisibles avec journalctl --list-boots.

Lab pratique

Rendre le journal systemd persistant après reboot

$ dsoxlab run l3-journald-persist

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l3-journald-persist
dsoxlab check l3-journald-persist

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• journalctl consulte le journal binaire de systemd, c'est l'outil de diagnostic principal sous Linux
• Filtrer par service (-u), par priorité (-p), par date (--since) et par boot (-b) pour cibler les informations utiles
• La persistance nécessite /var/log/journal/, Storage=persistent, et surtout journalctl --flush que tout le monde oublie
• Sur RHEL et AlmaLinux, /etc/systemd/journald.conf n'existe pas : passer par un drop-in sous journald.conf.d/, sinon on masque tous les défauts
• SystemKeepFree peut annuler SystemMaxUse : c'est la contrainte la plus stricte qui gagne
• Les priorités vont de 0 (emerg) à 7 (debug), commencer par -p err en cas de problème
• SystemMaxUse et MaxRetentionSec contrôlent la taille et la rétention du journal
• journalctl --vacuum-size et --vacuum-time permettent de nettoyer manuellement
• Le format JSON (-o json) facilite la centralisation vers Loki, Elasticsearch ou Graylog

×

📖 Voir la documentation →