systemd-journald est conçu pour archiver puis supprimer les vieux journaux (logs) selon une politique d'occupation de l'espace de stockage détails ici.
Parfois, on a besoin de conserver un journal un certain temps, ni plus, ni moins. Exemple ? L'obligation de conservation des données de connexion qui, en France, pèse sur les opérateurs de communications et les hébergeurs. Elles doivent être conservées 1 an. En dessous, l'opérateur / l'hébergeur ne remplit pas son obligation. Au-delà, le traitement est illégal au regard du RGPD car dénué de base légale (l'obligation légale court pour 1 an, pas plus).
Exemple moins pertinent : avec un volumineux système de stockage, on se retrouve avec 4 Go de journaux qui peuvent donc remonter loin et être pénibles à exploiter. Mais dans ce cas, on préférera affiner la valeur des paramètres de journald.
Pour une politique temporelle de conservation, journald propose le paramètre MaxRetentionSec. Source. Délai après lequel un journal contenant des entrées plus vieilles que ce délai sera supprimé. Par défaut, sa valeur est 0 afin de mettre en œuvre uniquement une politique de conservation basée sur l'occupation disque.
Il faut également configurer MaxFileSec. Un journal ne peut pas stocker des entrées au-delà de cette durée (1 mois par défaut). Un nouveau journal sera créé (et, l'ancien, archivé, donc supprimable). Il faut la positionner à « 1day ». Ainsi, lors de la suppression d'un journal archivé, après 1 an, seules les entrées d'il y a 366 jours seront supprimées. De même, seules les entrées du jour seront dans le journal courant, le reste sera archivé. Sans ce paramètre, soit journald supprimera le 12e mois (improbable), soit il conservera 1 an et 1 mois. Dans les deux cas, ça ne répond pas au besoin.
(Cette réflexion est basée sur le fait, qu'à priori, journald efface un journal en entier, pas les entrées d'un journal qui ont dépassé la date de péremption. Sa doc' consigne, pour le paramètre MaxFileSec : « However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. ». Et le manuel de journalctl
, pour l'action rotate, consigne : « Journal file rotation has the effect that all currently active journal files are marked as archived and renamed, so that they are never written to in future ».)
Conséquence logique : il faudra également modifier la valeur de SystemMaxFiles, car il y aura jusqu'à 1 an de journaux archivés chaque jour. Et il faudra désactiver la politique de conservation fondée sur l'occupation de l'espace de stockage (cf) sinon journald pourra supprimer des journaux récents si l'espace de stockage vient à manquer.
On peut aussi désactiver totalement ou partiellement journald (Storage). Il continuera à transmettre les journaux à rsyslog
(par défaut sous Debian), et on pourra les traiter à l'ancienne avec logrotate
.