Journaux sous Linux : journalctl, /var/log, rsyslog et logrotate

Quand un service tombe pendant la nuit, la réponse se trouve presque toujours dans les journaux : reste à savoir où les chercher. Sur les distributions actuelles (Ubuntu, Debian, RHEL, Fedora, Arch), les événements sont collectés par le service journald et se consultent avec la commande journalctl. En parallèle, de nombreux programmes écrivent des fichiers texte dans /var/log, dont la taille est surveillée par logrotate. Voici comment exploiter concrètement les journaux journalctl sous Linux, où se trouvent les autres, et comment ne pas perdre d'informations importantes lors de la rotation.

Où sont stockés les journaux sous Linux

Il existe trois sources, et il est utile de les garder en tête comme une carte :

• journald — le journal binaire de systemd. Il reçoit la sortie standard et la sortie d'erreur de tous les services, les messages du noyau et ceux de syslog. Il est stocké dans /var/log/journal/ (de façon permanente) ou dans /run/log/journal/ (jusqu'au redémarrage).
• /var/log — les fichiers texte. Ils sont écrits par rsyslog (par exemple /var/log/syslog, /var/log/auth.log) ou directement par les applications : nginx, PostgreSQL, MySQL.
• Le tampon circulaire du noyau — messages des pilotes et du matériel, affichés par dmesg ou journalctl -k.

La plupart des fichiers de /var/log ne sont accessibles qu'à root ou au groupe adm : les commandes de lecture doivent donc souvent être lancées avec sudo.

journalctl : commandes de base

Sans argument, journalctl affiche tout le journal, des plus anciennes aux plus récentes entrées, via le pager less. C'est rarement ce qu'on veut : on restreint généralement la sélection dès le départ.

journalctl              # tout le journal, des plus anciennes aux plus récentes
journalctl -e           # ouvrir directement à la fin
journalctl -n 50        # 50 dernières lignes
journalctl -r           # ordre inverse, les plus récentes en haut
journalctl --no-pager   # sans less, pratique pour les scripts et grep

Dans le pager, les touches habituelles de less fonctionnent : / — recherche, G — aller à la fin, q — quitter. Les longues lignes sont tronquées à la largeur de l'écran ; les flèches gauche et droite permettent de les faire défiler.

Journaux d'un service donné : journalctl -u

Le scénario le plus courant consiste à voir ce qu'un unit systemd a écrit. Inutile de chercher le fichier ni de passer par grep :

$ sudo journalctl -u nginx -n 20
Oct 14 03:12:41 web1 systemd[1]: Starting nginx.service - A high performance web server...
Oct 14 03:12:41 web1 nginx[1834]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Failed with result 'exit-code'.

L'option -u peut être répétée : journalctl -u nginx -u php8.2-fpm affiche les deux services mélangés selon l'heure, pratique lorsque l'erreur se produit à la jonction des deux. Pour les units utilisateur (systemctl --user), utilisez journalctl --user -u nom.

Journaux en temps réel : journalctl -f

sudo journalctl -u nginx -f

C'est l'équivalent de tail -f : la commande affiche les 10 dernières entrées puis attend les nouvelles. Pratique à garder dans un autre terminal pendant que vous redémarrez le service ou reproduisez l'erreur. On quitte avec Ctrl+C.

Filtres par date et par démarrage

Si vous connaissez le moment de la panne, sélectionnez les entrées avec --since et --until. Ces options acceptent aussi bien des dates précises que des valeurs relatives :

journalctl --since "2026-10-14 02:50" --until "2026-10-14 03:30"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl -u nginx --since "10 min ago"

Autre découpage utile : par démarrage du système. Si le serveur a redémarré tout seul, on cherche la cause à la fin de la session précédente :

$ journalctl --list-boots
 -2 8f1c...  Sat 2026-10-12 09:01:12 UTC  Sun 2026-10-13 22:47:03 UTC
 -1 a7d2...  Sun 2026-10-13 22:48:30 UTC  Tue 2026-10-14 03:05:51 UTC
  0 c3e9...  Tue 2026-10-14 03:07:02 UTC  Tue 2026-10-14 09:15:40 UTC

$ journalctl -b -1 -e      # fin du démarrage précédent
$ journalctl -b            # uniquement le démarrage en cours

La liste des démarrages n'est disponible que si le journal est stocké sur le disque. Pour l'activer, voir plus bas la section sur la configuration de journald.

Filtre par gravité : journalctl -p

Chaque entrée porte une priorité syslog de 0 à 7. L'option -p affiche le niveau indiqué et tous les niveaux plus graves :

journalctl -p err -b              # toutes les erreurs depuis le démarrage
journalctl -p warning..err -u ssh # plage de niveaux pour un seul service

La commande journalctl -p err -b est une bonne première vérification après un redémarrage ou une mise à jour : en quelques secondes, elle montre ce qui a mal tourné.

Recherche et autres filtres

journald conserve pour chaque entrée des champs structurés, et l'on peut filtrer sur eux sans grep :

journalctl _PID=1834                 # par numéro de processus
journalctl _COMM=sshd                # par nom de programme
journalctl _UID=1000                 # par utilisateur
journalctl /usr/sbin/sshd            # par chemin de l'exécutable
journalctl -k                        # uniquement les messages du noyau (comme dmesg)
journalctl -t CRON                   # par identifiant syslog
journalctl -g "Out of memory"        # recherche dans le texte, expression régulière

L'option -g (--grep) est apparue dans systemd 237 ; sur les anciens systèmes, utilisez un simple pipeline journalctl --no-pager | grep .... Les filtres sur différents champs se combinent par un « ET » : journalctl -u nginx -p err --since today ne renvoie que les erreurs nginx du jour.

Formats de sortie

L'option -o change le format. Les variantes les plus utiles :

• -o short-iso — heure au format ISO 8601, pratique pour la comparer aux journaux de l'application.
• -o verbose — tous les champs de l'entrée, y compris _SYSTEMD_UNIT, _PID, _BOOT_ID.
• -o json ou json-pretty — pour un traitement par script ou par jq.
• -o cat — seulement le texte du message, sans date ni nom d'hôte.

journalctl -u myapp -o json --since today | jq -r '.MESSAGE'

Configurer journald : stockage et taille

Les réglages se trouvent dans /etc/systemd/journald.conf (il est préférable de placer les modifications dans /etc/systemd/journald.conf.d/*.conf). Le paramètre principal est Storage :

• persistent — le journal est écrit sur le disque dans /var/log/journal et survit au redémarrage.
• volatile — uniquement en mémoire, dans /run/log/journal.
• auto (par défaut) — sur le disque si le répertoire /var/log/journal existe.

Sur certaines images minimales, ce répertoire est absent et l'historique disparaît au redémarrage. Pour activer le stockage permanent :

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

Pour que le journal n'occupe pas tout le disque, fixez des limites :

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

Par défaut, SystemMaxUse vaut 10 % de la taille du système de fichiers, sans dépasser 4 Go.

Comment vider le journal journalctl

$ journalctl --disk-usage
Archived and active journals take up 1.8G in the file system.

sudo journalctl --vacuum-size=300M   # garder 300 Mo au maximum
sudo journalctl --vacuum-time=2weeks # supprimer les entrées de plus de deux semaines
sudo journalctl --rotate             # fermer les fichiers actifs pour pouvoir aussi les supprimer

Il vaut mieux ne pas supprimer les fichiers de /var/log/journal avec rm : vacuum fait la même chose proprement et ne touche pas au fichier actif.

rsyslog : les journaux texte classiques

rsyslog est un démon qui reçoit les messages syslog (y compris ceux transmis depuis journald) et les répartit dans des fichiers selon des règles. La configuration se trouve dans /etc/rsyslog.conf et /etc/rsyslog.d/*.conf. Une règle se compose d'un sélecteur source.niveau et d'une action :

# /etc/rsyslog.d/50-default.conf (extrait)
auth,authpriv.*        /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.*                 -/var/log/kern.log

Le tiret devant le chemin signifie une écriture sans synchronisation sur le disque après chaque ligne : c'est plus rapide, mais en cas de panne les dernières lignes peuvent être perdues. Après modification de la configuration, vérifiez la syntaxe et redémarrez le service :

sudo rsyslogd -N1
sudo systemctl restart rsyslog

L'intérêt principal de rsyslog, qui justifie de le garder à côté de journald, est la transmission des journaux vers un serveur central. Une seule ligne suffit pour tout envoyer en TCP :

# /etc/rsyslog.d/90-remote.conf
*.* @@logs.example.com:514

Un seul @ désigne l'UDP, deux @@ le TCP. Si le serveur d'origine tombe entièrement, une copie des journaux reste sur une autre machine. Pour écrire votre propre message dans le journal système depuis un script, utilisez logger :

logger -t backup -p user.err "Échec de la sauvegarde de la base"
journalctl -t backup -n 5

logrotate : rotation des journaux

Les journaux texte grossissent sans fin, jusqu'à ce que quelqu'un les tronque. C'est le travail de logrotate : une fois par jour (via cron ou le timer logrotate.timer), il renomme le fichier courant, compresse les anciens et supprime les plus vieux. Les réglages généraux se trouvent dans /etc/logrotate.conf, et les règles propres à chaque programme dans /etc/logrotate.d/.

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Tester une règle sans rien modifier, ou lancer la rotation immédiatement :

sudo logrotate -d /etc/logrotate.d/myapp   # essai à blanc avec détails de débogage
sudo logrotate -f /etc/logrotate.d/myapp   # rotation immédiate

Erreur fréquente : oublier postrotate ou copytruncate. L'application continue alors d'écrire dans l'ancien app.log.1 via son descripteur, et le nouveau app.log reste vide.

Lire les journaux texte

Pour les fichiers de /var/log, les utilitaires standard suffisent :

sudo tail -n 100 /var/log/syslog          # dernières lignes
sudo tail -F /var/log/nginx/error.log     # suivre en survivant à la rotation
sudo less +G /var/log/auth.log            # ouvrir à la fin
sudo zgrep "Failed password" /var/log/auth.log.*.gz   # recherche dans les archives compressées
sudo grep -c " 500 " /var/log/nginx/access.log        # nombre de réponses 500

Remarquez le tail -F en majuscule : contrairement à -f, il rouvre le fichier lorsque logrotate le remplace.

Analyse pas à pas d'une panne

Le scénario « le service est tombé pendant la nuit » se traite dans l'ordre suivant :

1. systemctl status myapp — état actuel et dernières lignes du journal.
2. journalctl -u myapp --since "03:00" --until "03:30" — ce que le service a écrit au moment de la chute.
3. journalctl -p err -b — d'autres erreurs dans le système à la même période ?
4. journalctl -k --since "03:00" -g "Out of memory|Killed process" — l'OOM killer du noyau a-t-il tué le processus ?
5. Les journaux de l'application eux-mêmes dans /var/log/myapp/, archives .gz comprises.
6. Si le serveur a redémarré — journalctl -b -1 -e.

Conclusion

Pour le travail quotidien avec les journaux Linux, quelques commandes suffisent : journalctl -u pour un service, -f pour suivre le flux, --since et -p err pour réduire la sélection, -b -1 pour analyser un redémarrage. Les journaux texte se trouvent dans /var/log, rsyslog les répartit et les transmet, et logrotate ainsi que journalctl --vacuum-* empêchent les journaux de remplir le disque. Le travail avec journalctl, la rotation et le diagnostic de charge est détaillé en pratique dans une leçon du cours Linux.