GuiGui's Show

Sur un système GNU/Linux, logrotate est l'outil qui permet d'archiver périodiquement les journaux, de les compresser, puis de les supprimer en fonction d'une durée de conservation ou d'un volume d'espace disque occupé.

Il y a quelques petits pièges et trucs à savoir. C'est ce que nous allons voir.

Comprendre la directive « rotate »

Le manuel de logrotate expose : « Log files are rotated count times before being removed ». logrotate conservera donc X journaux en sus du journal courant / actuel. rotate 0 : dès la périodicité atteinte, le journal actuel ne sera pas archivé, il sera supprimé. rotate 1 : un journal archivé sera conservé en sus de l'actuel. rotate 2 = deux journaux archivés en sus du journal courant. Etc.

Donc la couverte sera minimum X * périodicité, maximum X+1 * périodicité. Si la périodicité est mensuelle :

• rotate 0 : le journal actuel sera effacé après un mois, donc tu gardes pile un mois d'historique, mais, dès le 1er jour du mois suivant, tu perds tout cet historique, y compris celui de la veille (dernier jour du mois précédent), donc la durée minimale de conservation est 0 ;
  
  
• rotate 1 : un journal actuel et un journal archivé, donc un message sera conservé deux mois au maximum (si elle a été consignée le premier jour du premier mois), et un mois au minimum (les entrées du 31e jour du mois X ne seront pas effacées le 1er jour du mois X+1) ;
  
  
• Ainsi rotate 12 conserve 12 mois minimum, 13 mois maximum (au dernier jour du 13e mois, dans le journal « .log.12.gz », tu auras des données qui remontent jusqu'au 1er jour d'il y a 12 mois. Au 31 juillet 2023, tu as les messages du 1er juillet 2022).

Durée de conservation glissante

La période est glissante. logrotate calcule la périodicité depuis son dernier passage. Il calcule donc un jour, une semaine, un mois, etc. depuis son dernier passage, pas depuis le premier jour d'une semaine ou d'un mois. (Il conserve ses états dans /var/lib/logrotate/status.)

C'est pour ça que si, avec une périodicité hebdomadaire (par ex.), on veut conserver un mois entier, de son 1er jour jusqu'à son dernier, rotate 4 peut ne pas suffire. Exemple : juillet 2023 est sur 6 semaines, de la semaine 26 (01-02/07) à la semaine 31 (31/07). Avec rotate 4, si logrotate archive le journal le lundi à 0 h, alors les 1 et 2 juillets, qui seront stockés dans le journal « log.4.gz », qui deviendra « log.5.gz » ce soir-là, seront effacés. S'il archive le mercredi, alors rotate 4 est suffisant. Mais cela ne se prévoit pas : on peut forcer le passage de logrotate le 1er jour d'une semaine ou d'un mois à la main avec -f, mais, par suite, le système peut être arrêté ou logrotate peut ne pas être exécuté pour toute raison, etc. rotate 5 (qui conserve au max 6 semaines) semble plus adéquat.

Autre exemple : weekly + rotate 4 sur le mois de juillet 2026 conduit logrotate à effacer, le dimanche 2 août 2026, le journal « .4.gz » qui contient les événements du mercredi 1er juillet 2026 au dimanche 5 juillet 2026. Dès lors, il manque 3 jours de logs pour avoir un mois complet.

Timer systemd

De nos jours, ce n'est plus CRON qui exécute logrotate mais un timer systemd (/lib/systemd/system/logrotate.timer), ce qui explique qu'il est désormais exécuté à minuit pile.

(L'usage usuel de CRON prévoit un mécanisme de lissage : les tâches planifiées quotidiennes, hebdomadaires et mensuelles sont lancées à des heures différentes entre elles et entre deux systèmes. Ces heures sont définies automatiquement lors de l'installation du système, cf. /etc/crontab. Généralement, ça tombe dans les 6 h du mat'.)

Pas de suppression des vieux journaux

logrotate ne supprime pas les vieux journaux au-delà de la périodicité configurée. Exemple : si tu passes de rotate 12 à rotate 1, les journaux existants nommés de « log.3.gz » à « log.12.gz » ne seront pas supprimés.

Comportements foireux avec copytruncate

Le mode de fonctionnement nominal de logrotate, c'est de renommer (et donc déplacer tant qu'on reste sur un même système de fichiers, cf. man 2 rename ;) ) le journal courant vers le dossier des archives puis d'exécuter un script pour informer le logiciel qui écrit dedans de passer à un nouveau fichier.

Certains logiciels ne prévoient pas cette fonctionnalité. Pour éviter de les redémarrer, logrotate propose la directive de config' copytruncate : le journal courant est copié dans les archives puis il est vidé (cf. man 2 truncate).

Jusqu'à la mi-2018, un bug rendait inopérante une directive rotate 0 cumulée avec copytruncate : le journal courant était copié, mais pas effacé.

logrotate propose un mode debug (logrotate -d </chemin/vers/la/config>) qui permet de tester toute la conf' ou seulement un fragment.

Quand on utilise copytruncate + rotate 0, la sortie du mode debug contient des incohérences. Exemple : « weekly 0 = weekly (no old logs will be kept) […] copying /var/log/.log to /var/log/archives//.log.1 » + il ne mentionne pas la suppression de .log.1. Si l'on regarde le code, le message de debug est affiché avant de tester si l'on est en rotate 0 et donc que la copie doit être évitée.

J'ai testé : rotate 0 produit concrètement le même effet avec ou sans copytruncate. C'est uniquement l'affichage du mode debug qui est erroné.

En revanche, avec copytruncate, il existe toujours un bug lors de la suppression du vieux journal. En mode normal, avec rotate 0, logrotate renomme le journal courant « log.1 » puis le supprime. Normal. En copytruncate, il fait pareil, mais il supprime aussi le fichier « log.2.gz » s'il existe. Ça n'a pas de sens : ce journal doit être supprimé uniquement avec rotate 1, comme en mode normal. De même que « log.3.gz » sera supprimé par rotate 2, etc. D'ailleurs, « log.2.gz » est aussi supprimé avec rotate 1 + copytruncate… Bref, il y a un bug quand rotate 0 et copytruncate sont utilisées en même temps mais ça n'a pas d'incidence sauf si l'on réduit la durée de conservation de son journal (log.2.gz sera alors peut-être effacé alors qu'on ne le souhaite pas).