Configurer logrotate pour gérer la rotation des logs sous Linux

logrotate archive, compresse et supprime automatiquement les anciens fichiers de log (/var/log/*.log). Tandis que journald gère le journal binaire de systemd, logrotate s'occupe des fichiers texte produits par les services qui écrivent directement dans /var/log/ (Nginx, Apache, MySQL, applications métier). Sans rotation, ces fichiers grossissent jusqu'à remplir le disque.

Ce que vous allez apprendre

• Comprendre l'architecture de logrotate (logrotate.conf + /etc/logrotate.d/)
• Lire et écrire une politique de rotation pour un service
• Utiliser les directives de compression, rétention et permissions
• Exécuter des scripts post-rotation (redémarrage de service)
• Tester une configuration sans risque et forcer une rotation manuelle
• Connaître la différence entre logrotate et journald

Dans quel contexte ?

logrotate est indispensable dès qu'un service écrit des fichiers texte, et les cas ci-dessous sont ceux qui remplissent un disque en production :

• Nginx ou Apache produisent des access.log et error.log qui peuvent atteindre plusieurs Go par jour sur un site actif
• Une application métier écrit ses logs dans /var/log/monapp/ sans aucune rotation intégrée
• Le disque /var se remplit et déclenche des alertes, il faut compresser et purger les anciens logs
• La conformité exige de conserver les logs 90 jours mais pas indéfiniment

LFCS / RHCSA

Aucun des deux référentiels publiés ne cite logrotate mot pour mot. La rotation sert l'objectif EX200 (RHEL 10) « Locate and interpret system log files and journals » : savoir où vivent les archives, comment elles sont nommées et pourquoi un log reste vide après une rotation.

logrotate et journald, deux rôles complémentaires

Les deux outils ne sont pas concurrents : chacun gère un type de log différent, et savoir lequel possède un fichier vous dit où chercher ses réglages de rétention.

Outil	Gère	Stockage	Configuration
journald	Journal binaire systemd	/var/log/journal/	journald.conf
logrotate	Fichiers texte classiques	/var/log/*.log	logrotate.conf + /etc/logrotate.d/

Glissez pour voir

Les deux coexistent sur un système moderne. journald capture les flux stdout/stderr des services systemd, les messages syslog et les logs du noyau. logrotate gère les fichiers texte que les services écrivent directement sur le disque.

Installation

logrotate est préinstallé sur la plupart des distributions. Sinon :

Debian/Ubuntu

sudo apt update && sudo apt install logrotate

RHEL/Fedora

sudo dnf install logrotate

Vérifiez ensuite la version installée. Elle a son importance : des directives comme maxsize ou hourly n'existent pas sur les versions anciennes. Une directive inconnue ne bloque pas le reste de la configuration, logrotate affiche unknown option '...' -- ignoring line (préfixé warning: en 3.22, error: en 3.21, mesuré) et poursuit, ce qui est pire qu'une erreur franche puisque la politique s'applique alors sans l'option que vous croyiez avoir posée.

# Vérifier la version
logrotate --version

logrotate 3.21.0

C'est la version d'Ubuntu 24.04 ; Debian 13 et AlmaLinux 10 livrent la 3.22.0 (mesuré le 2026-09-30).

Architecture de la configuration

La configuration de logrotate repose sur deux niveaux, et un fichier par service n'a qu'à dire ce qui diffère des valeurs globales :

Fichier	Rôle
/etc/logrotate.conf	Règles globales par défaut (fréquence, rétention)
/etc/logrotate.d/	Un fichier par service qui surcharge les règles globales

Glissez pour voir

Configuration globale

Ce fichier ne décrit aucun log en particulier : il pose les valeurs par défaut dont héritent tous les fichiers de /etc/logrotate.d/. Regardez d'abord les lignes commentées, elles vous disent ce qui n'est pas actif. Sur Ubuntu 24.04, dateext et compress sont livrés désactivés : croire le contraire fait chercher pendant longtemps pourquoi les archives sortent en .1 non compressé. Le fichier ci-dessous est celui d'Ubuntu 24.04 ; les deux autres distributions de référence s'en écartent, voir juste après la sortie.

cat /etc/logrotate.conf

# see "man logrotate" for details

# global options do not affect preceding include directives

# rotate log files weekly
weekly

# use the adm group by default, since this is the owning group
# of /var/log/.
su root adm

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
#dateext

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

Directive	Effet
weekly	Rotation hebdomadaire par défaut
rotate 4	Conserver 4 fichiers archivés
create	Créer un nouveau fichier après rotation
dateext	Suffixer les archives avec la date (-20260628)
compress	Compresser les archives (gzip)
include /etc/logrotate.d	Charger les configurations par service

Glissez pour voir

Les trois distributions ne livrent pas les mêmes valeurs actives, mesuré le 2026-09-30 : Debian 13 n'a pas la ligne su root adm, et AlmaLinux 10 active dateext, si bien que ses archives portent la date (-20260930) et non un numéro. Lisez donc le fichier de votre machine plutôt que celui d'un tutoriel.

La ligne include /etc/logrotate.d doit rester en dernier : les options globales déclarées après elle ne s'appliquent pas aux fichiers déjà inclus. Le fichier livré par la distribution le rappelle d'ailleurs en commentaire, dès sa troisième ligne.

Configuration par service

Chaque service place son fichier dans /etc/logrotate.d/, et ce fichier appartient au paquet : une modification à la main sera signalée comme conflit à la prochaine mise à jour. Voici le fichier livré par le paquet nginx sur Debian 13, relevé tel quel.

cat /etc/logrotate.d/nginx

/var/log/nginx/*.log {
  daily
  missingok
  rotate 14
  compress
  delaycompress
  notifempty
  create 0640 www-data adm
  sharedscripts
  prerotate
    if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
      run-parts /etc/logrotate.d/httpd-prerotate; \
    fi \
  endscript
  postrotate
    invoke-rc.d nginx rotate >/dev/null 2>&1
  endscript
}

Deux détails valent le détour. Le bloc prerotate exécute les scripts déposés par d'autres paquets dans httpd-prerotate, ce qui permet par exemple à un outil de statistiques d'analyser le log avant qu'il ne soit archivé. Et invoke-rc.d nginx rotate déclenche l'action rotate du script d'init, dont la fonction rotate_logs envoie le signal USR1 à Nginx (start-stop-daemon --stop --signal USR1) : ce n'est pas un reload complet, juste une réouverture des fichiers de log.

Directives essentielles

Fréquence

Ces directives ne déclenchent rien par elles-mêmes : elles décrivent une condition évaluée quand logrotate s'exécute, c'est-à-dire une fois par jour via le timer systemd. Écrire daily ne signifie donc pas « à minuit pile », mais « au plus une fois par jour, lors du passage ». La ligne size est à part : la page de manuel précise qu'elle est mutuellement exclusive avec les critères de temps, et que c'est la dernière directive écrite qui gagne.

Directive	Rotation
daily	Chaque jour
weekly	Chaque semaine
monthly	Chaque mois
size 100M	Quand le fichier dépasse 100 Mo

Glissez pour voir

Rétention

Les deux directives ci-dessous répondent à des questions différentes et se combinent très bien. rotate limite le nombre d'archives, ce qui borne l'espace disque ; maxage limite leur âge, ce qui répond à une exigence de conformité (« ne pas conserver les journaux au-delà de N jours »). Une limite à connaître : la page de manuel précise que l'âge n'est vérifié que lorsque le log tourne. Un fichier que notifempty écarte parce qu'il est resté vide ne tourne plus, et garde donc ses archives, maxage compris : pour ces logs dormants, seule une purge planifiée (un find -mtime dans un timer) borne l'âge.

Directive	Effet
rotate N	Garder N archives
maxage N	Supprimer les archives de plus de N jours

Glissez pour voir

Compression

La compression est le levier le plus rentable sur des logs texte : un access.log se réduit couramment d'un facteur 10 ou plus. La directive à comprendre est delaycompress, qui repousse la compression d'un cycle : la page de manuel précise qu'elle sert quand un programme ne peut pas être averti de fermer son fichier et continue donc d'écrire quelques instants dans l'ancien. Elle n'a d'effet qu'associée à compress.

Directive	Effet
compress	Compresser les archives (gzip)
delaycompress	Reporter la compression d'un cycle (utile si un service écrit encore)
compresscmd /usr/bin/bzip2	Utiliser bzip2 au lieu de gzip
nocompress	Désactiver la compression

Glissez pour voir

Changer la commande avec compresscmd change aussi l'extension : mesuré sur logrotate 3.21 et 3.22, compresscmd /usr/bin/bzip2 produit une archive .1.bz2, bien compressée en bzip2, sans aucune autre directive. La page de manuel le dit : l'extension de compressext « suit par défaut la commande configurée ». compressext ne sert donc qu'à imposer une autre extension, et uncompresscmd doit suivre la même commande pour que les outils de relecture ouvrent les archives.

Création du nouveau fichier

La directive create fixe les permissions et le propriétaire du fichier vide que logrotate met à la place de celui qu'il vient de tourner :

create 0640 root adm

Crée le nouveau fichier avec les permissions 0640, propriétaire root, groupe adm. Le service peut continuer à écrire immédiatement.

Sécurité

Ces trois directives évitent les deux échecs les plus fréquents en production : un fichier absent qui fait sortir logrotate en erreur, et un répertoire dont le propriétaire n'est pas root. su user group répond au second cas et son absence est la cause exacte du message error: skipping "..." because parent directory has insecure permissions, que logrotate complète lui-même par « Set "su" directive in config file » (mesuré sur les trois distributions). Traitez-la comme obligatoire dès que les logs vivent hors de /var/log.

Directive	Effet
missingok	Ne pas signaler d'erreur si le fichier n'existe pas
notifempty	Ne pas tourner un fichier vide
su root adm	Exécuter la rotation avec cet utilisateur/groupe (requis si le dossier a des permissions spéciales)

Glissez pour voir

Scripts pre et post-rotation

Les blocs prerotate et postrotate exécutent des commandes shell avant et après la rotation, typiquement pour que le service rouvre ses fichiers de log :

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 myapp myapp
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Bloc	Quand
prerotate ... endscript	Avant la rotation
postrotate ... endscript	Après la rotation
firstaction ... endscript	Avant la première rotation (une seule fois)
lastaction ... endscript	Après la dernière rotation (une seule fois)

Glissez pour voir

sharedscripts garantit que le script ne s'exécute qu'une seule fois, même si plusieurs fichiers correspondent au motif, au lieu de recharger le service une fois par fichier.

Pourquoi recharger le service ?

Après rotation, l'ancien fichier a été renommé. Le service continue à écrire dans le descripteur de fichier de l'ancien fichier (renommé). Le reload (ou kill -USR1) force le service à rouvrir ses fichiers de log et à écrire dans le nouveau fichier.

Tester et exécuter

Tester sans appliquer (mode debug)

Le flag -d est la première commande à lancer sur toute politique nouvelle ou modifiée :

sudo logrotate -d /etc/logrotate.d/nginx

Le flag -d simule la rotation et affiche ce qui serait fait, sans modifier aucun fichier ; logrotate --help le décrit comme « Don't do anything, just test and print debug messages ». Utilisez-le systématiquement avant de mettre en production une nouvelle configuration.

Dans la sortie, cherchez trois choses : la ligne <fichier>:<n> unknown option (préfixée warning: ou error: selon la version) qui signale une directive mal orthographiée, les lignes considering log qui montrent les fichiers retenus, et la conclusion par fichier (log needs rotating ou log does not need rotating). Un motif qui ne correspond à rien reste non développé : considering log /var/log/monapp/*.log, glob compris, sans conclusion. Sur un fichier que logrotate n'a jamais vu, la conclusion est log does not need rotating (log has already been rotated) : il enregistre ce premier passage comme point de départ, c'est normal.

Passé seul, un fichier de /etc/logrotate.d/ est lu sans /etc/logrotate.conf : les options globales ne s'appliquent pas. Mesuré sur AlmaLinux 10, dont la configuration globale active dateext, logrotate -f /etc/logrotate.d/<fichier> produit une archive numérotée .1 et non datée. Pour tester dans les conditions réelles, passez /etc/logrotate.conf.

Forcer la rotation

-f ignore les conditions de fréquence et de taille, et fait tourner immédiatement tout ce qui correspond au fichier de configuration passé en argument. C'est la commande de validation d'une nouvelle politique, pas une commande d'exploitation : chaque exécution consomme un cran du compteur rotate, donc l'enchaîner cinq fois efface vos cinq archives les plus anciennes.

# Forcer la rotation de tous les fichiers
sudo logrotate -f /etc/logrotate.conf

# Forcer la rotation d'un seul service
sudo logrotate -f /etc/logrotate.d/nginx

Mode verbose

Le flag -v affiche les détails de chaque rotation effectuée, utile pour suivre pas à pas une rotation forcée :

sudo logrotate -v /etc/logrotate.conf

Déclenchement automatique

Sur les distributions modernes, logrotate est déclenché par un timer systemd (et non plus par cron). Voici celui d'Ubuntu 24.04 :

systemctl cat logrotate.timer

[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Deux directives expliquent le comportement observé sur un serveur. AccuracySec=1h laisse à systemd une marge d'une heure pour regrouper ce réveil avec d'autres ; Debian 13 et AlmaLinux 10 portent à la place RandomizedDelaySec=1h, un délai aléatoire qui étale les rotations d'un parc de machines (mesuré le 2026-09-30). Dans les deux cas, l'heure exacte varie d'un jour et d'un serveur à l'autre, c'est normal. Persistent=true rattrape l'exécution manquée si la machine était éteinte au moment prévu, ce qui évite qu'un serveur allumé par intermittence n'accumule des logs jamais tournés.

# Vérifier que le timer est actif
systemctl status logrotate.timer

# Voir la prochaine échéance et la dernière exécution
systemctl list-timers logrotate.timer

cron ou timer ?

Debian 13 et Ubuntu 24.04 livrent encore /etc/cron.daily/logrotate, mais ce script s'arrête dès que systemd tourne (« skip in favour of systemd timer ») : le timer fait foi. AlmaLinux 10 ne livre plus de script cron. Sur un système sans systemd, c'est le script cron qui assure la rotation.

Écrire une politique complète

Voici un exemple de politique pour une application métier, de la création du fichier à la validation de la première rotation :

1. Créer le fichier de configuration

   sudo nano /etc/logrotate.d/monapp

2. Écrire la politique

   /var/log/monapp/*.log {
       daily
       rotate 30
       compress
       delaycompress
       missingok
       notifempty
       create 0640 monapp monapp
       su monapp monapp
       sharedscripts
       postrotate
           systemctl reload monapp > /dev/null 2>&1 || true
       endscript
   }

3. Tester la configuration

   sudo logrotate -d /etc/logrotate.d/monapp

   Vérification : la sortie doit afficher les fichiers qui seraient tournés, sans erreur de syntaxe.

4. Forcer une première rotation pour valider

   sudo logrotate -f /etc/logrotate.d/monapp
   ls -la /var/log/monapp/

   Vérification : un fichier .1 doit apparaître, non compressé : delaycompress repousse la compression au cycle suivant. Mesuré : un second -f produit .1 et .2.gz.

Dépannage

Les symptômes ci-dessous se distinguent par un critère simple : la rotation n'a pas eu lieu du tout (premières lignes) ou elle a eu lieu mais son résultat surprend (lignes suivantes). Commencez toujours par vérifier l'état du timer, car une rotation qui ne s'exécute jamais produit exactement les mêmes symptômes qu'une configuration invalide.

Symptôme	Cause probable	Solution
Logs jamais tournés	Timer désactivé	systemctl enable --now logrotate.timer
error: skipping "..." because parent directory has insecure permissions	Répertoire parent inscriptible par un groupe autre que root	Ajouter su <utilisateur> <groupe> au bloc
unknown option '...' -- ignoring line	Faute de frappe, ou directive absente de cette version	Corriger, et comparer avec logrotate --version
Logs tournés mais service écrit dans l'ancien	Pas de postrotate	Ajouter un bloc postrotate avec systemctl reload
error: ... duplicate log entry	Même fichier dans 2 configs	Vérifier /etc/logrotate.d/ pour les doublons
Archives non compressées	compress absent	Ajouter compress dans la configuration
Fichier .1 mais pas .1.gz	delaycompress actif	Normal, la compression s'applique au cycle suivant

Glissez pour voir

# Diagnostic rapide
systemctl status logrotate.timer          # Timer actif ?
sudo logrotate -d /etc/logrotate.conf     # Erreurs de config ?
ls -la /var/log/nginx/                     # Rotation effective ?
journalctl -u logrotate.service           # Dernière exécution ?

Bonnes pratiques

Les deux premières lignes vous éviteront les incidents, les suivantes vous éviteront de refaire le travail. Si vous n'en retenez qu'une, gardez la dernière : logrotate borne la rétention, pas le débit. Un service qui écrit 20 Go par jour remplira /var bien avant le passage quotidien du timer, et seul un plafonnement côté application ou un size agressif y changera quelque chose.

• Toujours tester avec -d avant de modifier une politique en production
• Utiliser delaycompress pour les services qui peuvent encore écrire dans l'ancien fichier pendant quelques secondes
• Ajouter sharedscripts + postrotate pour recharger le service après rotation
• Définir des permissions restrictives avec create, les logs contiennent souvent des informations sensibles (IP, erreurs, chemins)
• Configurer maxage en complément de rotate, pour supprimer à chaque rotation les archives trop anciennes même si le compteur n'est pas atteint
• Séparer les configurations dans /etc/logrotate.d/, un fichier par service, jamais tout dans logrotate.conf
• Surveiller l'espace disque, logrotate ne résout pas le problème si les logs croissent plus vite que la rotation

À retenir

• logrotate gère les fichiers de log texte, journald gère le journal binaire de systemd. Les deux sont complémentaires
• La configuration globale est dans /etc/logrotate.conf, les configurations par service dans /etc/logrotate.d/
• Les directives clés : daily/weekly, rotate N, compress, delaycompress, create, postrotate
• logrotate -d simule la rotation sans rien modifier, à utiliser avant chaque changement ; passé seul, un fichier de logrotate.d/ ignore les options globales
• logrotate -f force la rotation, utile pour valider une nouvelle configuration
• Le bloc postrotate recharge le service pour qu'il écrive dans le nouveau fichier
• Sur les systèmes modernes, logrotate est déclenché par un timer systemd (logrotate.timer), plus par cron

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →