journalctl : filtrer les logs d’un service sur une période précise
journalctl -u nginx –since yesterday sort les lignes du service sur la période demandée
Journalctl croise deux familles de critères, l’unité avec -u ou –unit, et la période avec -S/–since et -U/–until. Les deux se cumulent en ET logique : la page de manuel journalctl(1) publiée par Debian pour systemd 252.36-1~deb12u1 écrit que les contraintes ajoutées avec –boot ou –unit limitent encore le résultat. Le filtre d’unité ne montre pas que les lignes écrites par le processus, il ajoute les messages du gestionnaire au sujet de l’unité et ceux de ses coredumps, d’où des lignes de démarrage et d’arrêt inattendues. Un nom de service sans suffixe suffit, journalctl -u nginx vise la même unité que journalctl -u nginx.service. Trois commandes couvrent la plupart des besoins, la journée précédente, une plage horaire à la minute, ou les dernières minutes écoulées. La sortie garde une ligne par entrée, avec la date locale, le nom d’hôte, l’identifiant du programme et le message.
Sommaire
- journalctl -u nginx –since yesterday sort les lignes du service sur la période demandée
- Options de filtrage : portée, valeur par défaut et limite documentée
- –since lit l’anglais de systemd.time(7), pas le mot « hier »
- Sur une Debian 12 non modifiée, –since ne remonte pas avant le démarrage en cours
- Le journal persistant se limite à 10 % du système de fichiers, plafonné à 4 GiB
- Services utilisateur, motifs et priorités : trois filtres qui ne font pas ce qu’on croit
- Six arbitrages qui décident si la commande renvoie des lignes ou rien
- Sources
journalctl -u nginx --since yesterday
journalctl -u nginx --since "2026-09-18 08:00:00" --until "2026-09-18 12:00:00"
journalctl -u ssh.service --since "20 min ago"
journalctl -u nginx --since yesterday -n 200 --no-pager
Chaque ligne commence par la date locale, puis le nom d’hôte, le programme et le message. Un service silencieux ne casse rien, journalctl répond alors par une seule ligne, — No entries –, et la structure des unités est décrite dans le guide des journaux des services systemd.
Options de filtrage : portée, valeur par défaut et limite documentée
Douze lignes suffisent pour la grille des options utiles, et une seule valeur par défaut surprend vraiment, celle de -n. La page journalctl(1) livrée par Debian indique que –lines sans argument vaut 10 lignes, alors que journalctl sans -n affiche tout le journal accessible. Une priorité seule élargit le filtre au lieu de le resserrer, -p err inclut aussi les messages d’urgence et d’alerte. Le format de sortie compte pour la suite du travail, short reste le défaut, short-full produit des horodatages qui se recollent tels quels dans –since. La colonne des limites signale ce que la documentation reconnaît noir sur blanc, un filtre qui déborde, un mode qui exige un journal persistant, une option récente absente des vieilles distributions.
| Option | Filtre appliqué | Valeur par défaut | Limite documentée |
|---|---|---|---|
| -u, –unit=UNIT | entrées de l’unité, messages du gestionnaire et coredumps à son sujet | tout le journal accessible | accepte un motif visant plusieurs unités |
| –user-unit=UNIT | mêmes correspondances pour une unité de session | aucune | champ _SYSTEMD_USER_UNIT, que -u ne couvre pas |
| -S, –since=DATE | entrées datées de DATE ou après | début du journal conservé | fuseau local si la valeur n’en nomme pas |
| -U, –until=DATE | entrées datées de DATE ou avant | fin du journal conservé | date seule = 00:00:00, heure seule = jour courant |
| -n, –lines=N | nombre de lignes | 10 lignes si -n est seul | -f implique -n, -g avec -n inverse l’ordre |
| -p, –priority=N | priorités de 0 (emerg) à 7 (debug), ou plage A..B | tout le journal stocké | un niveau seul élargit, -p err couvre 0 à 3 |
| -g, –grep=MOTIF | champ MESSAGE par expression PCRE2 | aucune | minuscules = insensible à la casse, depuis systemd 237 |
| -b, –boot | entrées d’un démarrage, -1 pour le précédent | démarrage en cours | -b -1 exige un journal persistant |
| -o, –output=FORMAT | présentation des entrées | short | short-full (systemd 232) donne des dates recollables dans –since |
| -f, –follow | nouvelles entrées au fil de l’eau | arrêt en fin de journal | combinable avec -u et –since |
| –no-pager | pagination par less | less si la sortie est un terminal | SYSTEMD_PAGER vide produit le même effet |
| -r, –reverse | ordre du plus récent au plus ancien | ordre chronologique | activé par -g combiné à -n |
-o cat réduit chaque entrée au message seul et –utc affiche les horodatages en temps universel, sans changer la sélection.
–since lit l’anglais de systemd.time(7), pas le mot « hier »
Les dates acceptées par –since et –until suivent la page systemd.time(7) du projet systemd, qui impose l’anglais et ignore la locale du système. Sont compris today, yesterday, tomorrow, now, une date complète comme 2012-10-30 18:17:16, une heure seule comme 11:12, un horodatage relatif comme 20 min ago, -5h30min ou +3h30min, et un entier précédé de @ lu comme un temps Unix. Le mot « hier » n’appartient pas à cette grammaire, non plus que « il y a ». Une date sans heure vaut 00:00:00, une heure sans date se rattache au jour courant, et le fuseau par défaut reste celui du système sauf si la valeur nomme le sien, UTC ou Asia/Tokyo par exemple. La même page prévient qu’un horodatage affiché par une machine distante dans un fuseau non reconnu localement n’est généralement pas analysable sur place, ce qui limite la copie de dates entre serveurs.
journalctl -u nginx --since "20 min ago"
journalctl -u nginx --since "-2h" --until now
journalctl -u ssh --since yesterday --until today
journalctl -u nginx --since "2026-09-18 08:00" --until "2026-09-18 09:00"
Une valeur non citée produit l’erreur la plus fréquente de cette syntaxe, le shell coupe la plage horaire en deux arguments avant d’appeler la commande.
journalctl -u nginx --since 2026-09-18 08:00:00
Failed to add match '08:00:00': Invalid argument
La seconde moitié de la date arrive comme terme de correspondance, or journalctl n’accepte que des paires CHAMP=VALEUR. Le remède tient aux guillemets, un réflexe courant des commandes de base.
journalctl -u nginx --since "2026-09-18 08:00:00"
Sur une Debian 12 non modifiée, –since ne remonte pas avant le démarrage en cours
Journald conserve ses données sous /run/log/journal tant que le répertoire /var/log/journal n’existe pas, comme l’explique la page journald.conf(5) publiée par Debian, dont l’option Storage vaut auto par défaut. Une Debian 12 non modifiée démarre donc sans historique des démarrages précédents, et -b -1 n’a rien à retrouver. Le manuel ajoute que le service commence toujours en stockage volatil, puis bascule si journalctl –flush ou le service systemd-journal-flush.service l’y pousse. La règle ne dépend pas de la version du logiciel, elle vaut pour systemd 252.36-1~deb12u1 comme pour systemd 255.4 que Launchpad référence dans Ubuntu 24.04. Créer le répertoire ou écrire Storage=persistent suffit à changer de régime, sans redémarrer la machine.
journalctl -u nginx -b -1
Specifying boot ID or boot offset has no effect, no persistent journal was found.
Le diagnostic tient en deux commandes, la liste des démarrages connus et l’existence du répertoire.
journalctl --list-boots
ls -d /var/log/journal
Une seule ligne numérotée 0 accompagnée d’une erreur ls confirme le mode volatil.
- Créer le répertoire.
sudo mkdir -p /var/log/journalAttendu : aucune sortie, puis ls -d /var/log/journal affiche le chemin.
- Redémarrer le démon.
sudo systemctl restart systemd-journaldAttendu : systemctl status systemd-journald affiche active (running).
- Transférer ce qui attend en mémoire.
sudo journalctl --flushAttendu : la commande se termine sans message et le code de retour vaut 0.
- Contrôler la persistance.
journalctl --list-bootsAttendu : des lignes négatives apparaissent sous la ligne 0, dont -1 pour le démarrage précédent.
L’autre voie écrit Storage=persistent dans /etc/systemd/journald.conf, ce que la même page décrit comme l’équivalent d’un /var/log/journal présent.
Le journal persistant se limite à 10 % du système de fichiers, plafonné à 4 GiB
Selon la page journald.conf(5) livrée par Debian, SystemMaxUse accorde au journal persistant 10 % de la taille du système de fichiers, plafonnés à 4 GiB, tandis que SystemKeepFree réserve 15 % d’espace libre au reste du disque, et le démon retient la plus petite des deux limites. Le wiki Arch donne le même ordre de grandeur, 10 % de la partition avec un plafond souple de 4 GiB. Trois valeurs complètent le tableau, SystemMaxFiles garde 100 fichiers, MaxFileSec fait tourner un fichier au bout d’un mois, et chaque fichier plafonne à un huitième de SystemMaxUse dans la limite de 128 MiB. Seuls les fichiers archivés étant supprimés lors d’un nettoyage, l’occupation mesurée juste après peut dépasser la limite, un point que le manuel signale explicitement.
journalctl --disk-usage
sudo journalctl --rotate
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-time=2weeks
Une limite plus basse se règle dans un fichier déposé sous /etc/systemd/journald.conf.d, sans toucher au fichier principal.
[Journal]
SystemMaxUse=500M
Le redémarrage du démon applique la valeur, sudo systemctl restart systemd-journald. La rotation précède le nettoyage, sinon les fichiers en cours d’écriture restent hors de portée de –vacuum-size.
Services utilisateur, motifs et priorités : trois filtres qui ne font pas ce qu’on croit
Deux options voisines ne lisent pas le même journal, –unit parcourt les unités système et –user-unit celles de la session de l’utilisateur, et l’option –user convertit d’ailleurs tout -u en filtre d’unité utilisateur. La page journalctl(1) de Debian note aussi que -u accepte un motif, comparé à la liste des unités présentes dans le journal, et qu’une unité de type slice fait remonter les journaux de ses enfants. Les priorités ajoutent leur propre piège, -p 3 sélectionne les niveaux 0 à 3, donc plus la valeur est petite, plus la sortie est large. Un compte ordinaire, enfin, ne voit que son journal personnel, les groupes systemd-journal, adm et wheel ouvrant l’accès aux fichiers système.
journalctl --user-unit syncthing --since today
journalctl -u 'nginx*' --since today
journalctl -u nginx -p err --since yesterday
groups
Une extraction réutilisable se planifie, la routine planifiée reprend la même commande chaque nuit. Le détail des comptes et des permissions se trouve dans les guides Linux de la rubrique parente.
Six arbitrages qui décident si la commande renvoie des lignes ou rien
Combien d’espace disque le journal peut-il prendre avant de gêner ?
Le défaut documenté par journald.conf(5) est 10 % du système de fichiers, plafonné à 4 GiB, avec 15 % d’espace libre réservé. L’occupation réelle se lit avec journalctl –disk-usage, et sudo journalctl –vacuum-size=100M ramène les fichiers archivés sous 100 Mo. Un fichier en cours d’écriture échappe au nettoyage.
–since ou -b -1 : que choisir pour l’incident d’hier ?
Lancez d’abord journalctl –list-boots. Une seule ligne affichée signifie journal volatil, donc -b -1 répondra par le message sur l’absence de journal persistant, alors que –since yesterday reste exploitable dans les limites du démarrage en cours. Une liste qui descend jusqu’à -1 change la donne, –since garde la précision à la minute et -b -1 balaie un démarrage entier.
Quelle commande donne les 200 dernières lignes sans pagination ?
journalctl -u nginx -n 200 –no-pager. Sans argument, -n vaut 10 lignes, et -f implique cette valeur, donc un suivi en direct démarre sur dix lignes sauf ajout de –no-tail pour repartir de tout l’historique. La sortie brute convient aux scripts.
Pourquoi journalctl -u ssh ne renvoie rien alors que le service tourne ?
Le nom d’unité varie selon la distribution, ssh.service sur Debian et sshd.service sur la famille Red Hat. Comparez l’intitulé réel avec systemctl list-units –type=service, puis rejouez la requête avec le nom affiché. Un compte hors des groupes systemd-journal et adm ne voit que son journal personnel, ce qui produit le même silence.
Comment viser un service de session utilisateur plutôt qu’un service système ?
journalctl –user-unit syncthing –since today lit la session de cet utilisateur, une option décrite dans journalctl(1). L’option –user transforme même tout -u en filtre d’unité utilisateur pour la requête entière. Les unités de session sont indexées par _SYSTEMD_USER_UNIT, un champ que -u seul ne couvre pas.
Un horodatage venu d’une autre machine est-il exploitable dans –since ?
Rarement tel quel : systemd.time(7) prévient qu’un horodatage affiché par une machine distante avec un fuseau non reconnu localement n’est pas analysable sur place. Recopiez la valeur en la réduisant à UTC, du type 2026-09-18 08:00:00 UTC, une forme que la même page accepte. Sans mention de fuseau, la valeur est lue dans celui du système.