Rsyslog n'est pas maintenu?
Merci, je ne savais pas. Je vais regarder par quoi remplacer rsyslog demain au boulot.
Je parle de solution moderne et maintenue; après, il doit y avoir au moins dix autres solutions plus ou moins anciennes.Le lun. 30 juin 2025 à 21:41, Trak Hwsunix-based <trak.unixbased@gmail.com> a écrit :Bonjour.
Rsyslog ne fait pas l'affaire?
Avec un crontab on lance la gestion des logs.
Encore avec crontab on lance une commande pour supprimer les logs compressés vieux de X jours ou de ou size>×
Ca marche bien pour logstash qui est vraiment bavard ou pour les puits de logsLe lun. 30 juin 2025, 21:33, Jérémy Lal <kapouer@melix.org> a écrit :Le lun. 30 juin 2025 à 21:01, Informatique BILLARD <informatique@billard-francois-marie.eu> a écrit :Bonsoir
sans me souvenir comment je suis arrivé sur ce lien :
https://www.gnulinux-portugal.org/trouver-et-supprimer-des-fichiers-sous-linux/
mais il m'interroge sur le nettoyage d'un système Linux en l’occurrence Debian. Voici mes questions
Le plus important est de déterminer de quelle version de debian il s'agit. Si c'est une version récente (bookworm ou mieux, testing) ou pas (cas dont je ne parlerai pas).
- Faut-il vraiment mettre en place un système de nettoyage en ciblant quelques types de fichiers (tmp, log, ...) si oui lesquels ?
le pb avec les logs est principalement résolu grâce à journald, sauf dans certains cas particuliers (par exemple postgres, qui continue d'envoyer ses logs dans /var/log/postgres/, qui peut encore exploser).
- Si oui ne pouvons nous pas configurer le système pour qu'il ne produise pas tant de fichiers de ces types ?
C'est déjà configuré comme ça, sauf exceptions
- Quelles sont vos pratiques dans ce domaine ?
L'ancienne solution était de monter /var/log sur une partition, de fait, limitant le problème causé par son remplissage.Une bonne solution est de correctement configurer journald, et faire super gaffe aux applications spécifiques qui ne veulent pas logger par défaut vers journalctl.