Logs Linux : journalctl, rsyslog et rotation
À la fin de ce tutoriel, vous saurez interroger journalctl (
-u,-f,--since,-p err,-b), distinguer journal persistant et volatile, repérer les fichiers texte via rsyslog (/var/log/syslogoumessages), tester une conf logrotate lab dans/tmp, et corréler les extraits avecsystemctl status— le tout sur une VM jetable, sans secrets ni prod.Niveau : Intermédiaire · Temps estimé : 40–50 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11
Slug proposé :
linux-logs-journalctl· Série : Linux Admin · Remplace / fusionne : N/A — création (chapitre 2)
Prérequis
- Hub Linux Admin et chapitre 1 Processus avancés : niceness, cgroups et limites
- Bases processus & systemd (
systemctl, premiersjournalctl) - VM ou WSL jetable avec systemd ; compte non-root +
sudopour lire certains journaux et créer/var/log/journalen lab - Pas de secrets dans les logs lab ; travail dans
/tmppour logrotate
Coût estimé : 0 €. Lab : lectures journal + fichier + conf logrotate jetable sous /tmp/lab-logrotate.
Ce que nous allons construire
journalctl bases (-u, -f, --since, -p, -b)
→ Journal persistant vs volatile (/var/log/journal)
→ rsyslog aperçu · /var/log/syslog | messages
→ logrotate lab (/tmp) · idée /etc/logrotate.d/
→ Corréler systemctl status ↔ journalctl -u
→ Vérification + nettoyage
(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Logs Linux Admin : journalctl, journal persistant, rsyslog, logrotate ».)
Deuxième chapitre de Linux Admin. Après avoir borné les process, on observe : un OOM, un service qui boucle, un cron silencieux — tout passe souvent par les logs. journalctl interroge le journal systemd ; rsyslog alimente encore beaucoup de fichiers texte ; logrotate empêche /var/log de remplir le disque.
Étape 1 — Bases journalctl : -u, -f, --since, -p, -b
journalctl lit le journal binaire de systemd (pas un simple cat). Filtres du quotidien admin :
| Option | Rôle | Exemple |
|---|---|---|
-u UNIT |
Logs d’un unit | journalctl -u ssh |
-f |
Suivi live (Ctrl+C) | journalctl -u cron -f |
--since / --until |
Fenêtre temporelle | --since "1 hour ago" |
-p PRIORITÉ |
Seuil (emerg…debug) | -p err |
-b |
Boot courant (ou -b -1) |
journalctl -b -p warning |
-n N / --no-pager |
Dernières lignes / scriptable | -n 30 --no-pager |
# Choisir un unit sûr en lecture (adaptez selon la distro)
UNIT=$(systemctl list-units --type=service --state=running
'ssh*' 'sshd*' 'cron*' 'crond*' 2>/dev/null | awk '/.service/ {print $1; exit}')
UNIT=${UNIT:-cron.service}
echo "Unit observé : $UNIT"
journalctl -u "$UNIT" -n 20 --no-pager
journalctl -u "$UNIT" --since "2 hours ago" --no-pager | tail -n 15
journalctl -p err -b -n 25 --no-pager
# Suivi live (décommentez en interactif) :
# journalctl -u "$UNIT" -f
Priorités utiles : err, warning, info. -b isole le boot courant. Sur Rocky/Alma, noms d’units souvent sshd / crond ; flags journalctl identiques.
Étape 2 — Journal persistant vs volatile
Par défaut, certaines installs ne gardent le journal qu’en RAM (volatile sous /run/log/journal) : au reboot, l’historique disparaît. Le mode persistant écrit sous /var/log/journal (recommandé sur un VPS admin).
# Où vit le journal maintenant ?
ls -ld /var/log/journal /run/log/journal 2>/dev/null || true
systemd-analyze 2>/dev/null | head -n 1 || true
# Espace et rétention (aperçu)
journalctl --disk-usage
# Conf courante (extrait) — lecture
grep -E '^(Storage|SystemMaxUse|RuntimeMaxUse)'
/etc/systemd/journald.conf /etc/systemd/journald.conf.d/* 2>/dev/null ||
grep -E '^#?Storage=' /etc/systemd/journald.conf | head
| Mode | Emplacement typique | Après reboot |
|---|---|---|
| Volatile | /run/log/journal |
Historique perdu |
| Persistant | /var/log/journal |
Conservé (selon rétention) |
Activer le persistant en lab (VM jetable, avec sudo) :
# Lab optionnel — ne pas faire sur un hôte partagé sans accord
# sudo mkdir -p /var/log/journal
# sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null || true
# Puis dans journald : Storage=persistent (drop-in) + restart
# sudo mkdir -p /etc/systemd/journald.conf.d
# echo -e '[Journal]nStorage=persistentnSystemMaxUse=200M' | sudo tee /etc/systemd/journald.conf.d/99-lab-persistent.conf
# sudo systemctl restart systemd-journald
# journalctl --disk-usage
Prudence disque : un journal persistant sans
SystemMaxUse=peut grossir. Sur VPS petit, plafonnez (ex.200M) et surveillez avecjournalctl --disk-usage+df -h /var/log.
Étape 3 — rsyslog aperçu et fichiers /var/log
Beaucoup d’applis et de tutos historiques lisent encore /var/log/syslog (Debian/Ubuntu) ou /var/log/messages (famille RHEL). rsyslog (ou parfois syslog-ng) reçoit des messages (local, parfois réseau) et les écrit en texte. Le journal systemd et rsyslog coexistent souvent : systemd capture les units ; rsyslog alimente les fichiers classiques.
# Fichiers classiques (lecture — sudo parfois requis)
ls -la /var/log/syslog /var/log/messages /var/log/auth.log 2>/dev/null || true
# Dernières lignes texte (adaptez le chemin)
if [ -r /var/log/syslog ]; then
tail -n 15 /var/log/syslog
elif [ -r /var/log/messages ]; then
tail -n 15 /var/log/messages
else
sudo tail -n 15 /var/log/syslog 2>/dev/null || sudo tail -n 15 /var/log/messages 2>/dev/null ||
echo "Pas de syslog/messages lisible — OK, on reste sur journalctl"
fi
# Service rsyslog présent ?
systemctl is-active rsyslog 2>/dev/null || systemctl is-active syslog 2>/dev/null || echo "rsyslog inactif ou absent"
| Distro | Fichier texte fréquent | Auth / ssh |
|---|---|---|
| Ubuntu / Debian | /var/log/syslog |
/var/log/auth.log |
| Rocky / Alma | /var/log/messages |
/var/log/secure |
Pour un unit systemd, commencez par journalctl -u ; pour une appli fichier-only, tail / less sur /var/log/....
Étape 4 — logrotate : conf lab dans /tmp
logrotate archive, compresse et purge les fichiers qui grossissent. En prod, les snippets vivent sous /etc/logrotate.d/. Ici : lab 100 % dans /tmp — aucune conf système modifiée.
mkdir -p /tmp/lab-logrotate
# Fichier factice qui « grossit »
for i in 1 2 3 4 5; do
echo "$(date -Is) ligne lab $i" >> /tmp/lab-logrotate/app-lab.log
done
wc -l /tmp/lab-logrotate/app-lab.log
# Conf logrotate lab (chemins absolus /tmp)
cat > /tmp/lab-logrotate/app-lab.rotate << 'ROT'
/tmp/lab-logrotate/app-lab.log {
daily
rotate 3
missingok
notifempty
compress
delaycompress
copytruncate
}
ROT
# Forcer une rotation (dry-run puis réel)
logrotate -d /tmp/lab-logrotate/app-lab.rotate 2>&1 | tail -n 20
logrotate -f /tmp/lab-logrotate/app-lab.rotate
ls -la /tmp/lab-logrotate/
| Directive | Effet |
|---|---|
rotate 3 |
Garde 3 archives |
compress / delaycompress |
gzip (retardé d’un cycle) |
copytruncate |
Copie puis tronque (apps qui gardent le FD ouvert) |
missingok / notifempty |
Tolère absence / fichier vide |
En prod : snippet /etc/logrotate.d/, test sudo logrotate -d avant -f. Ne branchez pas une conf /tmp sur le conf global par inadvertance.
Étape 5 — Corréler systemctl status et journalctl
systemctl status affiche déjà un extrait récent du journal pour l’unit. journalctl -u permet d’élargir la fenêtre, de filtrer par priorité et de suivre en live. Enchaînement type incident :
UNIT=${UNIT:-cron.service}
# 1) Vue synthétique : Active? PID? dernières lignes
systemctl status "$UNIT" --no-pager -l | head -n 25
# 2) Historique élargi + erreurs
journalctl -u "$UNIT" --since "24 hours ago" -p warning --no-pager | tail -n 30
# 3) Lien process (rappel chapitre 1) — PID principal si actif
MAINPID=$(systemctl show -p MainPID --value "$UNIT" 2>/dev/null || echo 0)
if [ "${MAINPID:-0}" -gt 0 ] 2>/dev/null; then
echo "MainPID=$MAINPID"
tr ' ' ' ' < /proc/"$MAINPID"/cmdline 2>/dev/null; echo
fi
Workflow : status → journalctl -u -p err → limits/cgroup (ch. 1) si saturation → disques (ch. suivant) si /var/log plein.
Étape 6 — Vérification et nettoyage
# Vérifs lecture
journalctl -b -n 5 --no-pager >/dev/null && echo "journalctl OK"
journalctl --disk-usage
# Nettoyage lab logrotate uniquement (pas le journal système)
rm -rf /tmp/lab-logrotate
# Si vous avez créé un drop-in journald lab, retirez-le explicitement :
# sudo rm -f /etc/systemd/journald.conf.d/99-lab-persistent.conf
# sudo systemctl restart systemd-journald
ls /tmp/lab-logrotate 2>/dev/null || echo "lab logrotate nettoyé — OK"
Validé si : filtres journalctl OK, présence/absence de /var/log/journal identifiée, tail syslog|messages (ou sudo) OK, rotation lab visible sous /tmp avant nettoyage.
Erreurs fréquentes
| Symptôme | Cause | Correction |
|---|---|---|
journalctl vide pour un unit |
Mauvais nom / unit n’a jamais démarré | systemctl status pour le nom exact ; --since large |
| Historique perdu après reboot | Journal volatile | Activer Storage=persistent + /var/log/journal (lab) |
Permission denied sur /var/log/syslog |
Droits fichier | sudo tail ou groupe adm (Debian/Ubuntu) |
Disque /var plein |
Pas de rotation / journal sans plafond | logrotate + SystemMaxUse= ; journalctl --vacuum-size=100M (lab) |
logrotate ne fait « rien » |
notifempty / pas -f / mauvais chemin |
logrotate -d puis -f ; vérifier le glob |
| Confondre rsyslog et journal | Deux canaux | Unit systemd → journalctl ; fichier texte → tail/rsyslog |
-f bloqué en script CI |
Mode follow interactif | Utiliser -n / --since en non-interactif |
Quiz (3 questions)
1. Quelle commande suit en direct les logs d’un unit ?
– A. journalctl -u nom.service -f
– B. ulimit -n
– C. nice -n 10 journalctl
2. À quoi sert un journal persistant ?
– A. Supprimer rsyslog
– B. Conserver l’historique sous /var/log/journal après reboot
– C. Remplacer logrotate
3. Rôle principal de logrotate ?
– A. Compiler le noyau
– B. Archiver / compresser / purger des fichiers de log qui grossissent
– C. Changer la niceness d’un process
Réponses : 1‑A · 2‑B · 3‑B
FAQ
journalctl ou fichiers /var/log ?
Pour un service systemd, privilégiez journalctl -u (métadonnées, priorités, boots). Les fichiers syslog/messages restent utiles pour outils legacy, greps simples et applis qui n’écrivent pas au journal. Sur un VPS moderne, apprenez les deux.
Comment limiter la taille du journal ?
SystemMaxUse= (ex. 200M) dans un drop-in journald, puis systemctl restart systemd-journald. En urgence lab : sudo journalctl --vacuum-size=100M ou --vacuum-time=7d. Surveillez avec journalctl --disk-usage et df -h.
Où mettre une conf logrotate applicative ?
En prod : snippet sous /etc/logrotate.d/nom-app, test logrotate -d. En lab : fichier dédié sous /tmp comme ci-dessus, invoqué explicitement avec logrotate -f /chemin/conf — sans toucher au conf global.
Pour aller plus loin
man journalctl,man journald.conf,man logrotate,man rsyslog.conf- Hub Linux Admin · suite : disques et partitions (espace
/var/log)
Maillage série Linux Admin
| ← Précédent | Processus avancés : niceness, cgroups et limites |
| → Suivant | Disques et partitions : lsblk, fdisk, mount |
| Hub | Linux Admin |
| Aussi | Bases : processus & systemd |
Meta publication (à remplir dans Rank Math / SEO)
- Title SEO : journalctl Linux : logs, rsyslog et logrotate (2026)
- Meta description (≤ 155) : Lisez et filtrez les logs avec journalctl ; rsyslog et logrotate. Guide Linux Admin DevOps 2026.
- Focus keyphrase : journalctl
- KW secondaires : rsyslog, logrotate, persistent journal
- Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
- Image mise en avant :
assets/web/devopelastichayway/cover-linux-logs-journalctl-1200x630.webp(Visuels Linux — WebP 1200×630) - Catégorie : Linux · Niveau : Intermédiaire
- Slug :
linux-logs-journalctl - Statut : HOLD — draft only (ne pas publier)
← Retour parcours Linux — Basics, Admin, Réseau & Sécurité, Shell & Automation.