Palaiseau, le 23 juillet 2022
Cher Journal
Je note ici dès fois que ça serve à quelqu'un : depuis Debian 11, les journaux systèmes sont configurés pour grossir indéfiniment. Bien que l'intention de départ ne soit honorable, à savoir conserver des informations de dépannage et autres sortes d'enquêtes aussi longtemps que possible, l'espace disque n'est pas extensible à l'infini (n'en déplaise aux professionnels de l'infonuagique).
Une investigation avec du, ou bien ncdu qui est davantage adapté à la recherche de fichiers goinfres dans une arborescence, devrait montrer que beaucoup d'espace est consommé par /var/log/journal, en comparaison avec le reste des journaux systèmes :
$ sudo du -sh /var/log/* | sort -hr | head -n3 1.1G /var/log/journal 17M /var/log/apt-cacher-ng 16M /var/log/installer
Je fais du ménage relativement régulièrement, donc la consommation ne file pas, mais 1,1 Gio de consommé, c'est déjà particulièrement excessif pour du journal système. En comparaison, les fichiers de journaux historiques n'excèdent que rarement les quelque dizaines de mébioctets de taille ; bien entendu ces valeurs dépendent aussi beaucoup de l'usage de la machine :
$ sudo du -sh syslog* kern.log* auth.log* 2.8M syslog 3.5M syslog.1 620K syslog.2.gz 664K syslog.3.gz 592K syslog.4.gz 36K syslog.6.gz 24K syslog.7.gz 168K kern.log 48K kern.log.1 8.0K kern.log.2.gz 28K kern.log.3.gz 24K kern.log.4.gz 1.9M auth.log 2.8M auth.log.1 232K auth.log.2.gz 188K auth.log.3.gz 188K auth.log.4.gz
Le répertoire /var/log/journal contient l'intégralité des journaux systèmes dans un format de base de donnée binaire. Ce format n'est pas sans intérêt puisqu'il permet de retrouver facilement des informations diverses en fonction de nombreux paramètres, l'exemple typique étant de lister les évènements qui se sont produit sur une plage de temps quelque part dans le passé. On se référera avantageusement au manuel de journalctl(1) à ce sujet.
Historiquement, les journaux sont gardés sous contrôle au moyen d'outils comme logrotate(8). Les archives des journaux sous /var/log/journal sont gérées différemment, de part leur nature de base de données, qui se prête moins bien à rsyslog, mais mieux à d'autre formes de manipulations. La commande journalctl comprend un ensemble de commandes pour effacer les archives les plus anciennes, en fonction de la stratégie que tout un chacun voudrait appliquer. Il y a des stratégies pour conserver au moins un certain intervalle de temps, ou bien une certaine quantité de journaux, tout dépend des besoins de conservation des journaux. Typiquement, sur une machine sur laquelle je ne m'inquiète pas plus que ça des enregistrements de journaux, un bon ménage peut être fait avec :
$ sudo journalctl --vacuum-size=10M […]
$ sudo du -sh /var/log/* | sort -hr | head -n3 33M /var/log/journal 17M /var/log/apt-cacher-ng 16M /var/log/installer
Comme on peut le voir, la taille est légèrement supérieure après ménage. C'est parce que le répertoire contient différent types de bases de données. Il y a les journaux en cours d'écriture, et les journaux archivés. La partie des journaux archivés est la seule éligible à être nettoyée à coups d'aspirateur à données (vacuum), le reste étant en cours d'utilisation. Ça vaudrait probablement le coup de faire un ménage régulier pour éviter les incidents du type « disque plein ». Je me demande s'il y a une option de configuration pour désactiver la conservation ad vitam des journaux ? Autrement, passer un coup de d'aspirateur une fois tous les mois peut tout à fait se faire dans /etc/cron.monthly/.
Ça fait un bon bout de temps que je n'ai plus écrit grand chose dans ce journal. Quelque part, comme l'écrivait Soljénitsyne, c'est bon signe, ça veut dire que le reste avance. Ceci étant, la faute reposait probablement en bonne partie sur un clavier trop usé ; j'ai fini par en changer après avoir étudié de près les mécanismes disponibles sur le marché, de bonne réputation, et confortables à utiliser. Ce sera peut-être un sujet pour plus tard.
Name | Last modified | Size | |
---|---|---|---|
Parent Directory | - |