Bonjour à tous,
J’ai un système qui a peu de mémoire disque disponible mais qui fonctionne bien depuis plusieurs années. Mon logrotate est paramétré (weekly, size 300M) et est lancé par cron.daily.
De temps en temps, syslog grossit trop vite (plus de 8Go en 1 jour) et sature mon disque, ce qui plante l’ensemble.
Je n’ai pas encore trouver (pris le temps de chercher) l’origine de pb, mais j’aimerais savoir si un lecteur a une autre idée que passer logrotate à cron.hourly.
C’est beaucoup !
La priorité est bien sûr de trouver ce qui écrit autant dans le syslog et pourquoi, mais sinon tu peux aussi vérifier dans /etc/rsyslog.conf et/ou dans les fichiers de /etc/rsyslog.d si tu n’as pas trop de règles qui écrivent dans /var/log/syslog ou s’il y a des facilities dont tu peux te passer dans le syslog (cron, par exemple)
Dans ce cas, il faut mettre les yeux dedans et regarder ce qui est autant verbeux.
Quand ça m’arrive, j’ai deux méthode pour trouver le coupable :
- le temps réel : j’ouvre le fichier syslog avec tail dans un coin de mon écran et j’attends qu’un gros truc arrive
- le différé : des fois, je ne vois pas le gros truc et j’ai autre chose à faire que de rester devant l’écran à attendre, j’ouvre donc le fichier avec less et je pagine en regardant la vitesse de défilement du temps pendant la pagination
Après, je suis autiste, ce genre d’actions bizarres et manuelles sont mon mode de fonctionnement, il y a probablement moyen d’automatiser ça avec un script.
J’ai aussi remarqué quelque chose, quand tu as le syslog qui grossit vite, ça m’arrive plus souvent que ce soit des messages du noyau, tu peux commencer par chercher si ce n’est pas le noyau qui te pollue les journaux.
1 J'aime
Je te rassure beaucoup d’administrateur font comme ça sans être autiste ^^ (moi par exemple 
).
2 J'aime
+1
Et à la limite, si on ne compte pas lire les messages noyau dans le syslog (par exemple si on se contente de dmesg ou de kern.log) on peut enlever le noyau des facilities loguées dans le syslog.
Sinon, je me rappelle un exemple d’une appli java tierce installée avec un fichier systemd pour gérer le daemon, qui écrivait les logs applicatifs dans ses fichiers de log, mais aussi dans le syslog et dans /var/log/messages, et elle loguait des grosses stack error toutes les minutes. J’avais ajouté les lignes StandardOutput=null et StandardError=null dans le fichier de service, dans la section [Service], pour éviter de loguer les mêmes choses dans 3 endroits différents.
1 J'aime
Merci à tous pour vos réponses.
J’ai écrit ce post car j’avais décidé cette fois de comprendre le pb. J’avais donc, comme le suggère @Almtesh , réalisé une copie de mon syslog sur un autre système pour analyse en différé, avant de la détruire pour relancer la machine concernée.
Et je ne suis ne fier de vous annoncé ce que j’ai trouvé …
… des messages qui commencent le 14 février! (ce que j’aurais pu voir avec la date des logs précédents)
@Sputnik93 8Go en 10 mois c’est pas anormal 
J’ai pas encore compris pourquoi la rotation ne fait (elle se passe bien quand la lance manuellement et le cron semble être bien configuré, je vais suivre cela d’un peu plus près les semaines à venir.
Moi aussi qui suis fautif en l’occurrence.