Configurer logrotate : copytruncate, postrotate et test à blanc

Objectif

Ajouter ou modifier une règle de rotation pour le fichier journal d'une application, choisir la stratégie de rotation adaptée à la manière dont l'application y écrit, et valider la règle sans attendre la prochaine exécution planifiée.

Prérequis

Un accès root ; le chemin du fichier journal et la connaissance du comportement du processus écrivain : maintient-il le fichier ouvert en permanence ou le rouvre-t-il à chaque écriture ?

Étapes

1. Créer ou modifier une règle dans son propre fichier sous /etc/logrotate.d/, par exemple /etc/logrotate.d/myapp :

   /var/log/myapp/*.log {
       weekly
       rotate 8
       compress
       missingok
       notifempty
       postrotate
           systemctl kill -s HUP myapp.service
       endscript
   }
   

2. Choisir la stratégie de rotation. L'approche par défaut, qui renomme le fichier puis le recrée, exige que le processus écrivain rouvre le fichier ; cela se déclenche normalement depuis postrotate, en lui envoyant un signal (comme ci-dessus) ou en le rechargeant. Si l'on ne peut pas demander au processus de rouvrir son journal, utiliser copytruncate à la place : logrotate copie le fichier courant, puis tronque l'original sur place, de sorte que le processus conserve son descripteur de fichier d'origine. copytruncate risque de perdre les quelques lignes écrites entre la copie et la troncature ; un signal postrotate envoyé à un processus capable de rouvrir son journal évite ce trou, mais suppose que le processus traite correctement le signal.
3. Prévisualiser l'effet sans rien modifier : logrotate -d /etc/logrotate.d/myapp s'exécute en mode débogage (dry-run) et affiche ce qu'il ferait (rotation, omission ou aucune action, par exemple parce que notifempty écarte un fichier vide), sans rien écrire sur le disque.
4. Forcer une rotation hors planning pour les tests, en ignorant l'intervalle configuré et l'horodatage de la dernière rotation : logrotate -f /etc/logrotate.d/myapp. C'est la méthode habituelle pour valider immédiatement une nouvelle règle plutôt que d'attendre le prochain cycle weekly/daily.
5. Vérifier : l'ancien journal est renommé et compressé comme configuré, le nouveau fichier existe avec les permissions attendues issues de create (si cette directive est utilisée) et, pour un signal postrotate, le processus de l'application écrit bien dans le nouveau fichier (lsof <pid> montre le nouvel inode, ou de nouvelles lignes de journal apparaissent).

Résultat attendu

logrotate -d affiche les actions prévues sans erreur ; une exécution forcée avec -f produit le fichier tourné, et l'application continue de journaliser sans conserver un descripteur ouvert sur un ancien fichier qui grossirait indéfiniment.

Limites et base de vérification

Basé sur logrotate(8) et logrotate.conf(5). Pour annuler une règle défectueuse, modifier ou supprimer le fichier sous /etc/logrotate.d/ ; logrotate conserve son propre état dans un fichier de statut (généralement /var/lib/logrotate/status), si bien qu'une exécution de test forcée met quand même à jour l'horodatage de dernière rotation qui s'y trouve. Sauvegarder ce fichier de statut avant des tests répétés avec -f si le décompte de rotation de production (rotate N) ne doit pas être perturbé.