Re: exim+spamassassin: spamcheck transport output[solution v2]

[François Boisson <user.anti-spam@maison.homelinux.net>]

Je pensais avoir trouvé la raison du problème, eh ben non. Ce matin,
gel des trois démons spamd (mais aucun message perdu). La version 3.1.7
semble être prémunie contre ce bug 4950). Bon, suite des investigations.
Test sur des messages ayant gelé spamassassin, je constate que ces
messages passent très bien. Cela veut dire que le gel est indépendant
des messages. Peut être que cela vient de la grosseur de la base de
données, cela expliquerait que après chacune de mes interventions tout
se passe bien.

Fort de ces réflexions, je me rappelle de la fonction force-expire de
sal-learn, regardes les options de spamassassin et constate qu'il y a
une fonction auto_expire. Un recherche sur les news avec cette fonction
montre qu'elle entraine un grand délai de spamd avec également une
boucle infernale possible sur le verrouillage de la base bayes. Je
teste donc une nouvelle configuration qui supprime l'auto-expire et je
rajoute dans le crontab, juste après le sa-learn --sync quotidien un
sa-learn --force-expire. Si ma théorie est juste, cela devrait
enfin résoudre mon problème. En conclusion:

* spamc appelé avec une option -t 60
* spamd avec l'option  --create-prefs  --timeout-child=60
                             --max-children 3 -c --helper-home-dir
* Rajout de l'option bayes_auto_expire 0 dans local.cf
use_bayes 1
bayes_auto_learn 1
bayes_auto_expire 0
* Appel quotidien de sa-learn --force-expire


Ce coup là, ça devrait être bon :)

François Boisson