On ne parle pas de la même chose. Je conseille ici quelque chose qui a à
voir avec une installation debian.
Or, par défaut, c'est journald qui est installé, et non rsyslog (qui est,
mea culpa, très bien maintenu).
Le lun. 30 juin 2025 à 21:47, Trak Hwsunix-based <
trak.unixbased@gmail.com>
a écrit :
Rsyslog n'est pas maintenu?
Merci, je ne savais pas. Je vais regarder par quoi remplacer rsyslog
demain au boulot.
Le lun. 30 juin 2025, 21:44, Jérémy Lal <kapouer@melix.org> a écrit :
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 logs
Le 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).
1. 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). >>>>
1. 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
1.
2. 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.
<div dir="ltr"><div>On ne parle pas de la même chose. Je conseille ici quelque chose qui a à voir avec une installation debian.</div><div>Or, par défaut, c'est journald qui est installé, et non rsyslog (qui est, mea culpa, très bien maintenu).</
<br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le lun. 30 juin 2025 à 21:47, Trak Hwsunix-based <<a href="mailto:trak.unixbased@gmail.com">trak.unixbased@gmail.com</a>> a écrit :<br></div><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Rsyslog n'est pas maintenu? <br>
Merci, je ne savais pas. Je vais regarder par quoi remplacer rsyslog demain au boulot. </p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 30 juin 2025, 21:44, Jérémy Lal <<a href="mailto:
kapouer@melix.org" target="_blank">
kapouer@melix.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Je parle de solution moderne et maintenue; après, il doit y avoir au moins dix autres solutions plus ou moins anciennes. </div><br><div class="gmail_quote"><
div dir="ltr" class="gmail_attr">Le lun. 30 juin 2025 à 21:41, Trak Hwsunix-based <<a href="mailto:
trak.unixbased@gmail.com" rel="noreferrer" target="_blank">
trak.unixbased@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Bonjour. </p>
<p dir="ltr">Rsyslog ne fait pas l'affaire?<br>
Avec un crontab on lance la gestion des logs.<br>
Encore avec crontab on lance une commande pour supprimer les logs compressés vieux de X jours ou de ou size>×<br>
Ca marche bien pour logstash qui est vraiment bavard ou pour les puits de logs </p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 30 juin 2025, 21:33, Jérémy Lal <<a href="mailto:
kapouer@melix.org" rel="noreferrer" target="_blank">
kapouer@melix.org</a>> a écrit :<br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 30 juin 2025 à 21:01, Informatique
BILLARD <<a href="mailto:
informatique@billard-francois-marie.eu" rel="noreferrer noreferrer" target="_blank">
informatique@billard-francois-marie.eu</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-
left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Bonsoir</p>
<p>sans me souvenir comment je suis arrivé sur ce lien :</p>
<p><a href="
https://www.gnulinux-portugal.org/trouver-et-supprimer-des-fichiers-sous-linux/" rel="noreferrer noreferrer" target="_blank">
https://www.gnulinux-portugal.org/trouver-et-supprimer-des-fichiers-sous-linux/</a></p>
<p>mais il m'interroge sur le nettoyage d'un système Linux en
l’occurrence Debian. Voici mes questions<br></p></div></blockquote><div><br></div><div>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).</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<ol>
<li>Faut-il vraiment mettre en place un système de nettoyage en
ciblant quelques types de fichiers (tmp, log, ...) si oui
lesquels ?</li></ol></div></blockquote><div>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). </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><ol>
<li>Si oui ne pouvons nous pas configurer le système pour qu'il ne
produise pas tant de fichiers de ces types ?<br></li></ol></div></blockquote><div>C'est déjà configuré comme ça, sauf exceptions </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);
padding-left:1ex"><div><ol><li>
</li>
<li>Quelles sont vos pratiques dans ce domaine ?<br></li></ol></div></blockquote><div><br></div><div>L'ancienne solution était de monter /var/log sur une partition, de fait, limitant le problème causé par son remplissage.</div><div>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.</div><div><br></div></div></div>
</div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)