journalctl : analyser les logs systemd et les conserver durablement

Un serveur qui ne tourne pas rond a le plus souvent déjà consigné ce qui s'est passé. Le problème n'est pas l'information manquante, mais la quantité dans laquelle elle se noie. Qui lance journalctl sans argument atterrit au tout début du journal et fait défiler des semaines de messages. Ce guide montre comment découper, en trois ou quatre commandes, exactement la portion qui correspond à l'incident.

L'article Créer un service systemd présente les formes de base -u, -b et -f. Ici, il est question de tout ce qui vient ensuite : plages horaires, filtres, priorités, formats de sortie, conservation durable du journal, limites de taille, messages du noyau et motifs de recherche prêts à l'emploi.

Toutes les indications valent pour Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Les commandes sont écrites pour une exécution en tant que root. Si vous travaillez avec un compte utilisateur normal, faites précéder chaque commande de sudo.

Avant de modifier quoi que ce soit : le chemin du retour

Lire le journal ne présente aucun risque, aucune commande de recherche de cet article ne modifie le système. Trois choses seulement sont risquées, et elles viennent toutes plus loin.

Un système de fichiers saturé. Sans limite propre, le journal occupe jusqu'à dix pour cent du système de fichiers, avec un plafond à quatre gigaoctets. Sur un petit volume de stockage, un /var plein est le plus court chemin vers un serveur qui n'accepte plus aucune connexion.

Une faute de frappe dans la configuration. systemd ignore les clés inconnues au lieu d'arrêter le service. Votre limite figure alors dans le fichier sans produire le moindre effet, et personne ne vous le signale spontanément.

Un nettoyage prématuré. journalctl --vacuum-time=1d supprime de façon irréversible, y compris les preuves que vous êtes justement en train de chercher.

La voie de secours pour le pire des cas : sur les serveurs root KVM et les serveurs dédiés de KernelHost, il n'y a ni IPMI ni iDRAC. L'accès qui fonctionne même sans réseau, c'est la console VNC dans l'espace client. Elle est rattachée à la couche de virtualisation, ou au raccordement lui-même, et non à la pile réseau du système invité. Connectez-vous-y une fois au préalable, et assurez-vous de connaître le mot de passe root.

État des lieux en cinq commandes

systemctl --version | head -n 1

systemctl is-active systemd-journald

journalctl --disk-usage

ls -d /var/log/journal /run/log/journal

df -h /var

La quatrième commande est la plus importante : elle répond à la question de savoir si votre journal survit à un redémarrage, et renvoie No such file or directory pour celui des deux répertoires qui n'existe pas. Toutes les modifications de cet article iront plus tard dans un fichier séparé sous /etc/systemd/journald.conf.d/. Le fichier /etc/systemd/journald.conf livré par la distribution reste intact, et le retour en arrière tient en deux commandes : supprimer le fichier, redémarrer le service.

Délimiter une plage horaire plutôt que faire défiler

Presque tout incident porte un horodatage. C'est par là que commence l'analyse, pas par le nom du service.

journalctl --since "-30min"

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20"

journalctl --since yesterday --until today

--since et --until ont pour formes courtes -S et -U. Comme indication de temps, journalctl comprend des valeurs absolues de la forme 2026-09-02 03:10:00, des dates sans heure (minuit s'applique alors), les mots-clés yesterday, today, tomorrow et now, ainsi que des valeurs relatives comme -1h, -30min ou 2 days ago.

Un piège coûteux en temps se cache ici : journalctl travaille dans l'heure locale du serveur, alors que les applications consignent souvent en UTC. Reprenez tel quel, dans --since, un horodatage issu d'un log applicatif, et en été vous chercherez deux heures à côté de l'événement. Vérifiez le fuseau, ou faites-vous tout afficher directement en UTC :

timedatectl

journalctl --since "2026-09-02 01:10" --until "2026-09-02 01:20" --utc --no-pager

Vérification : si -- No entries -- revient, soit la fenêtre est trop étroite, soit le fuseau est faux. Élargissez la fenêtre à une heure à titre de test avant de douter des filtres.

Les démarrages comme plage horaire

Souvent, la bonne portion n'est pas un intervalle horaire mais un démarrage du système. -b sans valeur désigne le démarrage en cours, -b -1 celui d'avant.

journalctl --list-boots --no-pager

journalctl -b -1 -p err --no-pager

La liste affiche une ligne par démarrage, avec un index, et le démarrage en cours porte le 0. Si cette seule ligne apparaît, le journal n'est probablement pas conservé de façon durable. -b -1 répond alors sur Debian 13 par No journal boot entry found for the specified boot (-1) et sur Ubuntu 24.04 par No journal boot entry found from the specified boot offset (-1). Ce n'est pas une panne, c'est l'annonce qu'il n'y a rien à en tirer.

Filtrer par service, processus et priorité

L'unité, et pourquoi son nom doit être exact

journalctl -u nginx.service --since "-2h" --no-pager

-u compare sur l'égalité, pas sur la ressemblance. Il en découle une erreur particulièrement désagréable, parce qu'elle ne produit aucun message d'erreur : sur un système Debian avec MariaDB, journalctl -u mysql renvoie -- No entries -- alors que le journal déborde de messages de la base de données. mysql.service n'y est qu'un alias de mariadb.service. systemctl résout ces alias, tandis que le journal enregistre sous le vrai nom. Vous obtenez donc une réponse fausse qui n'a pas l'air d'une erreur.

Le vrai nom, vous allez le chercher dans le journal lui-même. -F liste toutes les valeurs qu'un champ y a prises un jour :

journalctl -F _SYSTEMD_UNIT | sort | grep -i sql

-u accepte par ailleurs des motifs, ce qui désamorce la question :

journalctl -u "mysql*" -u "mariadb*" -n 60 --no-pager

La même vérification vaut le coup sur Ubuntu 24.04 pour SSH, car le service y démarre par activation de socket et les connexions ne figurent pas forcément sous le nom attendu :

journalctl -F _SYSTEMD_UNIT | grep -i ssh

L'identifiant plutôt que l'unité

À côté de l'unité, il y a l'identifiant de l'émetteur, c'est-à-dire ce que le syslog classique retient comme nom de programme. Le filtre correspondant est -t :

journalctl -t sshd -t sshd-session -n 50 --no-pager

Pourquoi deux ? Depuis la version 9.8, OpenSSH déporte les sessions dans un processus distinct sshd-session. Sur Debian 13 (OpenSSH 10.0), il ne reste donc sous -t sshd que le fait que le service écoute, alors que chaque connexion se trouve sous -t sshd-session. Debian 12 (9.2), Ubuntu 24.04 (9.6) et Ubuntu 22.04 (8.9) ne connaissent pas cette séparation. Sur Debian 13, filtrer uniquement sur -t sshd revient à croire qu'un serveur est tranquille alors que chaque tentative contre lui est en train d'être consignée. Le passage par l'unité est plus robuste, car les processus enfants relèvent de la même unité :

journalctl -u ssh --since "-24h" --no-pager

N'importe quel champ, et la façon dont ils se combinent

Chaque entrée porte des champs que vous pouvez écrire directement comme filtre, par exemple _COMM (nom du programme), _PID, _UID, _SYSTEMD_UNIT ou _TRANSPORT. Les règles de combinaison sont souvent mal comprises :

• Deux filtres sur des champs différents se combinent avec un ET.
• Deux filtres sur le même champ se combinent avec un OU.
• Un simple signe plus entre deux groupes relie ces groupes avec un OU.

journalctl _SYSTEMD_UNIT=ssh.service _UID=0 --since "-1h" --no-pager

journalctl _SYSTEMD_UNIT=ssh.service + _SYSTEMD_UNIT=nginx.service --since "-1h" --no-pager

Les noms de champ s'écrivent en majuscules et la comparaison porte sur la valeur complète. Un journalctl unit=nginx n'est donc pas un filtre sur une sous-chaîne, mais une erreur de syntaxe que journalctl sanctionne par Failed to add match.

Les priorités

Chaque entrée porte un niveau d'urgence de 0 à 7. -p filtre dessus, toujours en incluant tous les niveaux plus urgents : -p err affiche aussi crit, alert et emerg.

journalctl -b -p err --no-pager

journalctl -u nginx.service -p 2..4 --since "-24h" --no-pager

Et voici maintenant l'écueil sur lequel le filtrage par priorité échoue régulièrement : ce qu'un service écrit sur la sortie standard atterrit par défaut dans le journal en info, même si cela passait par la sortie d'erreur standard. Un programme qui affiche une exception avec sa trace d'appels apparaît ainsi comme un message d'exploitation anodin, et -p err le masque. Seuls obtiennent un niveau adapté les programmes qui écrivent directement sur l'interface du journal ou qui font précéder leurs lignes d'un préfixe syslog comme <3>. Pour vos propres services, filtrez donc par unité et par texte ; pour les services système et pour le noyau, -p est en revanche tout à fait utilisable.

Recherche de texte

journalctl -u nginx.service --since "-24h" --grep "upstream timed out" --no-pager

--grep (forme courte -g) ne parcourt que le texte du message, pas les autres champs. La casse est ignorée automatiquement tant que le motif est entièrement en minuscules ; dès qu'une majuscule apparaît, la comparaison devient exacte. Les deux comportements se forcent avec --case-sensitive=yes ou --case-sensitive=no. Les expressions régulières sont autorisées, la barre verticale agit donc comme un OU.

Suivre le journal en direct

-f s'accroche à la fin du journal et affiche les nouvelles lignes dès qu'elles arrivent. Cela n'a de sens qu'avec un filtre, sinon la moitié du système défile. -n détermine combien de lignes antérieures apparaissent d'abord ; sans indication, ce sont dix. On quitte avec Ctrl+C.

journalctl -u nginx.service -f -n 100

journalctl -f -u nginx.service -u php8.2-fpm.service

journalctl -f -p warning

Le déroulé habituel pour une erreur reproductible : suivre le journal dans une première session, déclencher l'erreur dans une seconde. Avec des lignes très larges, -o cat aide, puisque seul le texte du message apparaît alors, sans horodatage ni émetteur.

Vérification : si rien n'arrive au moment du déclenchement, le service n'écrit pas dans le journal mais dans un fichier à lui. Pour les serveurs web et les bases de données, c'est le cas normal. Le chemin passe alors par la configuration de l'application, pas par d'autres options de journalctl.

Les formats de sortie

Le format par défaut est conçu pour un humain devant un terminal. Pour la mise en correspondance avec d'autres logs, pour les pipes et pour les analyses, il en existe de plus adaptés. On bascule avec -o :

journalctl -u ssh.service -n 1 -o verbose --no-pager

Cette seule commande vaut mieux que n'importe quelle liste de champs dans un tutoriel : vous voyez quels champs vos entrées portent réellement, et vous pouvez ensuite utiliser chacun d'eux comme filtre. Quatre options complètent le tableau :

• --no-pager désactive le pager. Dans les scripts et devant chaque pipe, elle est indispensable, sinon l'appel attend une touche que personne n'appuie.
• -r inverse l'ordre, les lignes les plus récentes se retrouvent en haut.
• -e saute immédiatement à la fin dans le pager.
• -x ajoute, pour les messages propres à systemd, un texte de catalogue explicatif.

Avec --output-fields=, la sortie se réduit aux champs qui vous intéressent. Cela n'agit que sur verbose, json et les formats apparentés :

journalctl -u ssh.service --since "-1h" -o json --output-fields=MESSAGE,_PID --no-pager

Conserver le journal au-delà des redémarrages

Le fait que le journal survive à un redémarrage, c'est le réglage par défaut Storage=auto qui en décide, selon une règle simple : si /var/log/journal existe, l'écriture s'y fait et tout est conservé. S'il n'existe pas, tout atterrit dans la RAM sous /run/log/journal et disparaît au prochain redémarrage. Ne vous fiez pas à la distribution, les deux états se rencontrent selon les variantes d'installation et les images cloud. Un journal en RAM est l'explication la plus fréquente au fait que, après un plantage, plus personne ne peut dire ce qui s'était passé avant.

Si vous basculez, fixez la limite dans la même opération. L'expérience montre que cela ne se fait plus après coup :

mkdir -p /etc/systemd/journald.conf.d

cat > /etc/systemd/journald.conf.d/10-kh-journal.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month
EOF

systemctl restart systemd-journald

journalctl --flush

Storage=persistent crée le répertoire lui-même, un mkdir n'est pas nécessaire pour cela. journalctl --flush reprend ce qui se trouve encore dans /run et le déplace vers /var/log/journal.

Vérifications, dans cet ordre :

systemd-analyze cat-config systemd/journald.conf | grep -v '^#'

ls -d /var/log/journal

journalctl -u systemd-journald -b -n 20 --no-pager

La première commande montre la configuration effective, issue du fichier principal et de tous les fichiers complémentaires, c'est-à-dire ce que le service a réellement lu. La troisième est le test de la faute de frappe : si une ligne contenant Unknown key y figure, votre réglage n'a aucun effet. Selon la version de systemd, elle s'écrit Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring ou Unknown key 'SystemMaxUsage' in section [Journal], ignoring.

La preuve définitive, c'est un vrai redémarrage. Ensuite, journalctl --list-boots doit afficher au moins deux lignes et journalctl -b -1 -n 20 doit livrer des entrées. Si vous préférez créer le répertoire à la main, empruntez le chemin suivant. L'appel à systemd-tmpfiles pose au passage le propriétaire, les droits et les listes de contrôle d'accès qui autorisent les groupes concernés à lire :

mkdir -p /var/log/journal

systemd-tmpfiles --create --prefix /var/log/journal

systemctl restart systemd-journald

Lire sans être root

Un utilisateur normal ne voit que ses propres messages et reçoit en prime l'indication Hint: You are currently not seeing messages from other users and the system., accompagnée du renvoi vers les groupes autorisés à tout lire. Sur Debian et Ubuntu, il s'agit habituellement du groupe adm :

usermod -aG adm nomdutilisateur

Vérification : l'appartenance au groupe ne prend effet qu'à une nouvelle connexion. Déconnectez-vous donc, reconnectez-vous, puis lancez id -nG et journalctl -n 5. Si l'indication disparaît et que des messages système apparaissent, c'est réussi.

Limiter la taille avant que le disque ne s'en charge

Le fichier /etc/systemd/journald.conf livré par la distribution énumère toutes les clés en lignes commentées avec leurs valeurs par défaut, et c'est donc la source la plus fiable sur ce qui s'applique en ce moment à votre système. Après chaque modification, systemctl restart systemd-journald est nécessaire, puis journalctl --disk-usage montre le résultat.

Pour la mesure d'urgence sur un disque plein, un ordre s'impose, et beaucoup s'y trompent : les options de nettoyage ne touchent que les fichiers de journal clos, jamais celui qui est actif. Sans rotation préalable, il ne se passe apparemment rien, et la sortie dit en substance Vacuuming done, freed 0B of archived journals.

journalctl --rotate

journalctl --vacuum-time=7d

Vous en saurez plus, avec les autres dévoreurs d'espace, dans l'article Disque plein sous Linux.

Une deuxième cause de lignes manquantes est la limitation de débit intégrée, via RateLimitIntervalSec et RateLimitBurst : si un service écrit énormément de messages en peu de temps, journald jette le surplus et le signale par une ligne contenant le mot Suppressed. Quand un journal présente des trous alors que le service tournait de façon avérée, cherchez d'abord cela :

journalctl -b --grep "Suppressed" --no-pager

Messages du noyau : journalctl -k et dmesg

-k n'affiche que les messages du noyau et englobe au passage -b, ce qui limite donc automatiquement la sortie au démarrage en cours. Si vous cherchez la cause après un redémarrage, vous devez demander le démarrage précédent de façon explicite :

journalctl -k -p err --no-pager

journalctl -k -b -1 --no-pager

La différence avec dmesg tient à l'emplacement de stockage. dmesg lit le tampon circulaire du noyau : de taille limitée, il déborde, et il est vide après un redémarrage. Le journal conserve les mêmes messages, à condition d'être persistant. Pour un incident survenu hier, journalctl -k est donc la seule source fiable. Deux remarques de terrain à ce sujet : dmesg -T convertit en heures les secondes écoulées depuis le démarrage et se décale légèrement après de longues durées de fonctionnement, alors que le journal porte toujours l'heure réelle. Et kernel.dmesg_restrict vaut 1 sur les quatre distributions, un appel sans root échoue donc avec Operation not permitted.

Pourquoi beaucoup de serveurs n'ont plus de /var/log/syslog

Le journal n'est pas un complément aux fichiers texte classiques, il les remplace. /var/log/syslog et /var/log/auth.log ne naissent pas de systemd, mais d'un service syslog supplémentaire, généralement rsyslog. Celui-ci est un paquet à part et, sur les installations minimales de Debian 12 et Debian 13, il ne fait plus partie de la livraison. Sur les images serveur d'Ubuntu 22.04 et 24.04, il est présent.

ls -l /var/log/syslog /var/log/auth.log

systemctl status rsyslog --no-pager

Si aucun service syslog n'est installé, la seconde commande répond Unit rsyslog.service could not be found. Cela explique trois observations d'un seul coup : les tutoriels avec tail -f /var/log/syslog échouent sur tail: cannot open '/var/log/syslog' for reading: No such file or directory, la recherche de tentatives de connexion dans /var/log/auth.log ne donne rien, et fail2ban doit puiser ses événements dans le journal. La façon de le régler est décrite dans l'article configurer fail2ban.

Installer rsyslog après coup, uniquement par habitude de ces fichiers, se justifie rarement : vous stockez alors tout en double et il vous faut en plus une règle logrotate qui fonctionne. Cela devient pertinent lorsque les logs doivent partir vers un système central.

Des motifs de recherche prêts à l'emploi pour les cas d'urgence

Un service est mort ou redémarre en boucle

systemctl list-units --type=service --state=failed --no-pager

journalctl -b -p err --no-pager

journalctl -b --grep "Main process exited|Failed with result|Start request repeated" --no-pager

La troisième ligne trouve les messages par lesquels systemd signale les plantages et l'entrée en action de son limiteur de démarrages intégré. Si un vidage mémoire de plantage devient intéressant, ce fichier indique d'abord qui s'en charge :

cat /proc/sys/kernel/core_pattern

Si un appel à systemd-coredump y figure, coredumpctl list énumère les vidages disponibles. S'il y a autre chose, ou seulement core, c'est un autre gestionnaire qui s'en occupe et coredumpctl reste vide.

Manque de mémoire

journalctl -k -b --grep "Out of memory|oom-kill" --no-pager

journalctl --since "-7d" --grep "Out of memory|oom-kill" --no-pager

journalctl -u systemd-oomd --since "-7d" --no-pager

La deuxième commande renonce sciemment à -k et cherche ainsi au-delà des démarrages successifs. La troisième vaut pour Ubuntu 22.04 et 24.04, où systemd-oomd tourne d'origine et termine des control groups entiers avant que le noyau n'intervienne ; sur Debian, ce service ne fait pas partie de l'installation par défaut. La façon de distinguer ces messages les uns des autres est expliquée dans l'article Configurer le swap et éviter les Out-of-Memory.

Connexions échouées

journalctl -u ssh --since "-24h" --grep "Failed password|Invalid user" --no-pager

Ce qui est plus intéressant que les lignes prises une à une, c'est leur répartition. La ligne suivante compte les adresses source et les trie par ordre décroissant :

journalctl -u ssh --since "-24h" -g "Failed password" -o cat --no-pager | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

L'astuce, c'est le comptage à partir de la fin : le message se termine toujours par from ADRESSE port NUMERO ssh2, le quatrième champ en partant de la fin est donc l'adresse, peu importe qu'un nom d'utilisateur valide ou inventé l'ait précédé et qu'il s'agisse d'IPv4 ou d'IPv6. -o cat est ici obligatoire, car sinon l'horodatage et l'émetteur décalent le comptage des champs. La contre-épreuve pour les connexions réussies :

journalctl -u ssh --since "-7d" -g "Accepted (publickey|password)" -o cat --no-pager

Que s'est-il passé à 03:14, et qu'y avait-il avant ?

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20" -o short-iso --no-pager

journalctl -b -1 -n 100 --no-pager

journalctl _PID=1234 --since "-1h" --no-pager

La deuxième commande affiche les cent dernières lignes avant la fin précédente. Vous reconnaissez un arrêt ordonné au fait que systemd y termine les services les uns après les autres. Si la sortie s'interrompt en plein fonctionnement normal, il s'agissait d'un plantage, d'un reset matériel ou d'une coupure de courant. Pour la troisième commande, retenez ceci : les numéros de processus sont réutilisés, et sans plage horaire vous mélangez peut-être deux programmes différents dans une même sortie.

Erreurs fréquentes et solutions

No journal files were found. : il n'existe aucun fichier de journal lisible. Soit systemd-journald ne tourne pas, soit vous n'avez pas les accès nécessaires en tant qu'utilisateur normal. Vérifiez d'abord avec systemctl is-active systemd-journald, puis recommencez en tant que root.

-- No entries -- : le filtre n'a rien trouvé. Ce n'est pas un message d'erreur, mais une réponse correcte à une question peut-être mal posée. Les trois causes les plus fréquentes : un nom d'unité qui n'est qu'un alias, une plage horaire trop étroite, et un -k alors que le message recherché ne venait pas du tout du noyau.

Hint: You are currently not seeing messages from other users and the system. : vous lisez en tant qu'utilisateur normal. Faites-vous ajouter au groupe adm puis reconnectez-vous, ou travaillez directement avec sudo.

No journal boot entry found for the specified boot (-1) ou No journal boot entry found from the specified boot offset (-1) : le journal ne contient aucun démarrage antérieur. C'est le cas normal tant que le journal ne réside qu'en RAM.

Failed to add match : l'expression n'est pas un filtre de champ valide. Les noms de champ s'écrivent en majuscules et la comparaison porte sur la valeur complète. Pour les correspondances partielles dans le texte du message, c'est --grep qui s'en charge.

Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring : une faute de frappe dans le fichier complémentaire. systemd passe la ligne et continue avec la valeur par défaut. À retrouver via journalctl -u systemd-journald -b.

Vacuuming done, freed 0B of archived journals : il n'y avait rien d'archivé à supprimer, parce que c'est le fichier actif qui occupe la place. D'abord journalctl --rotate, puis relancez le nettoyage.

Operation not permitted avec dmesg : kernel.dmesg_restrict vaut 1. Recommencez en tant que root ou repliez-vous sur journalctl -k.

File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing. : le serveur s'est arrêté brutalement alors qu'un fichier de journal était ouvert. journald ajoute un tilde à l'ancien nom et commence un nouveau fichier. L'état de tous les fichiers se vérifie avec journalctl --verify, qui affiche une ligne avec PASS par fichier ; les anomalies signalées concernent en règle générale précisément les anciens fichiers portant le tilde.

Différences entre Debian 13, Debian 12, Ubuntu 24.04 et 22.04

• Debian 13 (trixie) : systemd 257. OpenSSH 10.0, les connexions figurent sous l'identifiant sshd-session. rsyslog absent des installations minimales, /var/log/syslog manque alors. systemd-oomd ne fait pas partie de l'installation par défaut.
• Debian 12 (bookworm) : systemd 252. OpenSSH 9.2, tout se trouve sous sshd. rsyslog présent selon la variante d'installation, /var/log/syslog n'est donc pas garanti. systemd-oomd ne fait pas partie de l'installation par défaut.
• Ubuntu 24.04 LTS : systemd 255. OpenSSH 9.6, tout se trouve sous sshd. rsyslog présent. systemd-oomd actif d'origine. SSH passe par une activation de socket, allez donc relever le nom d'unité réel dans le journal.
• Ubuntu 22.04 LTS : systemd 249. OpenSSH 8.9, tout se trouve sous sshd. rsyslog présent. systemd-oomd actif d'origine. La plus ancienne des quatre versions de systemd, certains formats de sortie récents y manquent.

L'essentiel reste identique sur les quatre systèmes : les mêmes filtres, les mêmes priorités, le même fichier de configuration et la même règle voulant que /var/log/journal décide de la durée de conservation.

L'ordre qui a fait ses preuves au quotidien : d'abord la plage horaire, puis l'unité, puis la priorité, et pour finir un motif de recherche. En procédant ainsi, vous n'avez pas besoin de trois commandes pour la plupart des incidents. Et si vous faites une bonne fois en sorte que le journal survive aux redémarrages tout en respectant une limite supérieure, vous pourrez encore répondre à la question du pourquoi bien après que le serveur a redémarré.