Et voilà, un petit script et un cron plus tard (ou plutôt l’équivalent sur Mac OS X) et ce fichu process — censé protéger des accès répétés et frauduleux et qui à force prend un embonpoint plus gros que ce qui est raisonnablement admissible sur une telle machine — va maintenant marcher droit, c’est à dire se faire violemment tuer toutes les heures, si jamais il dépassait le seuil limite !
En test sur un de mes (vieux) serveurs jusqu’à demain, je déploierai ensuite sur les deux autres (vieux) serveurs histoire d’être tranquille pendant mes vacances. En effet, ce process gourmand m’a valu de passer une demi-journée à bosser au lieu de jouer avec les copains de la colonie Dotclear, ce qui est proprement un scandale, n’est-ce pas ?
Je suis donc globalement satisfait \o/
1 De Otir -
J’admire la constance dont tu fais preuve.
2 De Franck -
Merci Otir :-)
3 De Nicolas -
logrotate ne faisait pas l’affaire ?
Tu peux spécifier de manière cumulée une date et une taille de fichier ce qui permet de ne pas remplir le système de fichiers : http://doc.ubuntu-fr.org/logrotate#…
Tu peux aussi limiter le nombre de fichiers de logs à garder. Du coup tu maîtrises parfaitement la taille prise par les logs.
4 De Franck -
Dans ce cas précis, logrotate ne sert à rien puisque c’est pour pallier une fuite mémoire d’un process et pas la taille d’un fichier log.
J’aurais du préciser ça, en effet, il s’agit de RAM pas de place occupée sur le disque.