Lire les journaux avec journalctl

Module 6: Services et journaux · Temps de lecture : 11 minutes

Objectif pédagogique : À l'issue de cette leçon, vous savez chercher de manière ciblée dans les journaux de votre serveur avec journalctl (par service, par priorité et par période), vous savez où se trouvent les autres fichiers journaux et vous évitez que les journaux remplissent votre disque.

Notions clés : journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, priorité (err, warning, info), stockage persistant, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Le journal, premier témoin

Lorsque quelque chose ne fonctionne pas sur votre serveur, la raison se trouve presque toujours dans un journal. Un site web qui affiche une page d'erreur, un service qui ne démarre pas, une sauvegarde qui ne s'est pas exécutée cette nuit : le serveur l'a noté. Un bon administrateur consulte d'abord le journal, et ne modifie quelque chose qu'ensuite.

Sur les serveurs Linux modernes, journald (qui fait partie de systemd) rassemble les messages du noyau, de systemd lui-même et de tous les services dans un seul registre : le journal. Vous le lisez avec journalctl.

Pour pouvoir tout lire, vous devez faire partie du groupe adm ou systemd-journal, ou utiliser sudo. Sans ces droits, vous ne voyez que vos propres messages.

Où est-il stocké ? Persistant ou volatil

journald conserve le journal à l'un de deux endroits :

• dans /var/log/journal/ : persistant, les journaux sont conservés après un redémarrage ;
• dans /run/log/journal/ : volatil, en mémoire, perdu après un redémarrage.

Le réglage par défaut (Storage=auto dans /etc/systemd/journald.conf) choisit le mode persistant si le dossier /var/log/journal/ existe. Sur Debian, le paquet systemd crée ce dossier depuis Debian 11, et il existe aussi sur Ubuntu. Vérifiez-le :

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Si vous ne voyez qu'un seul démarrage alors que le serveur a déjà redémarré, vos journaux sont volatils. Créez le dossier (sudo mkdir -p /var/log/journal et sudo systemd-tmpfiles --create --prefix /var/log/journal) puis redémarrez journald. C'est important : après un plantage, vous voulez justement savoir ce qui s'est passé avant le redémarrage.

Depuis Debian 12, Debian n'installe plus rsyslog par défaut. Ce programme écrivait autrefois des fichiers texte comme /var/log/syslog et /var/log/auth.log. Sur un nouveau serveur Debian, ces fichiers n'existent donc pas ; tout se trouve dans le journal. Ubuntu dispose encore de rsyslog. Lorsqu'un guide vous dit « regardez dans /var/log/auth.log », vous pouvez le traduire sur Debian par journalctl -u ssh.

Chercher : les filtres que vous utiliserez vraiment

Sans filtre, journalctl affiche tout, en commençant par le plus ancien. C'est rarement ce que vous voulez. Les principaux filtres, que vous pouvez combiner :

Les priorités vont de 0 (emerg) à 7 (debug) : emerg, alert, crit, err, warning, notice, info, debug. Avec -p err, vous obtenez err et tout ce qui est plus grave. -p warning affiche aussi les avertissements.

Un parcours de recherche typique. Depuis ce matin, votre site web renvoie une erreur 502 :

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

La cause y figure en toutes lettres : une faute de frappe à la ligne 42 d'un fichier de configuration. Le statut 78 (CONFIG) confirme qu'il s'agit d'une erreur de configuration. Inutile de deviner.

Deux conseils pour la lecture :

• Lisez de haut en bas et cherchez la première erreur. Une erreur provoque souvent toute une série de messages consécutifs. La première est généralement la cause.
• Faites attention à l'heure. Qu'est-ce qui a changé à ce moment-là ? Une mise à jour automatique (leçon 4.2 : /var/log/unattended-upgrades/), une modification de votre part, un redémarrage ?

Autres fichiers journaux

Tout ne se trouve pas dans le journal. De nombreux programmes écrivent aussi (ou uniquement) leurs propres fichiers dans /var/log/ :

Vous lisez les gros fichiers texte avec less (recherche avec /), la fin avec tail -n 50, en direct avec tail -f, et vous filtrez avec grep :

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Les journaux des conteneurs Docker ne se trouvent pas dans /var/log mais chez Docker lui-même : docker compose logs (leçon 9.3).

Les journaux ne doivent pas remplir votre disque

Un disque plein est l'une des causes les plus fréquentes d'un serveur qui cesse « soudainement » de fonctionner : les bases de données s'arrêtent, les mises à jour échouent, parfois vous ne pouvez même plus vous connecter. Les journaux en sont souvent responsables.

Le journal se limite lui-même. Par défaut, il utilise au maximum 10 % du système de fichiers, avec un plafond de 4 Go (SystemMaxUse=). Voici comment voir combien il occupe actuellement et comment faire le ménage :

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # suppression au-delà de 30 jours
anna@web1:~$ sudo journalctl --vacuum-size=500M    # jusqu'à 500 MB

Si vous voulez une limite fixe, placez dans un fichier drop-in /etc/systemd/journald.conf.d/grootte.conf :

[Journal]
SystemMaxUse=1G

puis redémarrez journald avec sudo systemctl restart systemd-journald.

Les fichiers texte de /var/log sont gérés par logrotate : chaque jour ou chaque semaine, un fichier est renommé (error.log.1), les versions plus anciennes sont compressées (.gz) et les plus anciennes supprimées. Les règles par programme se trouvent dans /etc/logrotate.d/. Les paquets de la distribution apportent leur propre règle. Si l'un de vos programmes ou scripts écrit dans son propre fichier journal, créez vous-même une règle, sinon le fichier grossira sans fin.

Trouver ce qui occupe de la place :

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Journaux et vie privée

Les journaux contiennent des adresses IP, des noms d'utilisateur et parfois des adresses e-mail : ce sont des données personnelles. Ne les conservez pas plus longtemps que nécessaire (quelques semaines à quelques mois est courant pour un petit serveur), ne les laissez pas accessibles publiquement (un dossier /logs dans votre racine web est une erreur classique) et ne les copiez pas à la légère vers les services de tiers.

Sur AlmaLinux et Rocky Linux

journalctl fonctionne de la même façon. Sur ces systèmes, rsyslog est encore activé par défaut, avec des fichiers comme /var/log/messages et /var/log/secure (l'équivalent de auth.log). Les messages de SELinux se trouvent dans /var/log/audit/audit.log ; ausearch -m avc -ts recent affiche les refus récents.

Résumé

• journald rassemble tous les messages dans le journal ; lisez-le avec journalctl, filtré par service (-u), priorité (-p), période (--since) et démarrage (-b).
• Vérifiez que le journal est persistant (/var/log/journal existe), sinon vous perdez vos journaux après un redémarrage.
• Debian 12 et les versions suivantes n'ont pas rsyslog par défaut, donc pas de /var/log/auth.log ni de /var/log/syslog ; tout se trouve dans le journal.
• Cherchez la première erreur et regardez ce qui a changé à ce moment-là.
• Surveillez la taille : le journal se limite lui-même (--disk-usage, --vacuum-*), logrotate gère les fichiers texte.

Quiz

Exercice

Exercice Z6.2 : Analyser un service qui plante. Le fichier d'exemple journal-crash-1.txt contient la sortie de systemctl status et de journalctl pour un service qui redémarre sans cesse puis abandonne. Répondez : comment s'appelle le service, combien de fois systemd a-t-il tenté de le démarrer, avec quel code de sortie s'est-il arrêté, quelle est la cause d'après le premier message d'erreur, et à quelle heure systemd a-t-il abandonné ? Le programme compare vos réponses à la clé de correction. Vérifiez ensuite sur votre propre serveur si journalctl -p err -b affiche des erreurs et si votre journal est persistant.

Pour aller plus loin

• Manuel de journalctl(1) : https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Manuel de journald.conf(5) (Storage=, SystemMaxUse=) : https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, notes de publication 5.1.7 (rsyslog n'est plus installé par défaut) : https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html