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

Par défaut sur la plupart des distributions, le journal est persistant si /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 :

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

Configurer explicitement la persistance

Pour être sûr, configurez Storage=persistent dans /etc/systemd/journald.conf (voir la section Configuration).

Consulter les logs

Logs du dernier boot

# 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

# 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

# Équivalent de tail -f
journalctl -f

# Suivre un service spécifique
journalctl -fu nginx

Filtrer par date

# 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

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

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

Logs du noyau

# É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 de configuration principal est /etc/systemd/journald.conf :

sudo nano /etc/systemd/journald.conf

Options essentielles

[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 :

sudo systemctl restart systemd-journald

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

Réduire par taille

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

Réduire par ancienneté

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

Réduire par nombre de fichiers

# 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é

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

Symptôme	Cause probable	Solution
Journal vide après reboot	Persistance non configurée	Créer /var/log/journal/ et configurer Storage=persistent
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

• 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/ et Storage=persistent dans journald.conf
• 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 →