un problème un peu compliqué que je n'arrive pas à résoudre.
Sur une debian sarge avec un Spamassassin de volatil puis un backport
de spamassassin de Etch:
J'ai des mails qui se perdent avec des erreurs notées:
2007-03-10 06:47:34 unexpected EOF while reading SMTP data (header)
from mail
2007-03-10 06:47:34 1HPuLd-0003hL-00 <user.anti-spam@m...et>:
spamcheck transport output: An error was detected while processing a
file of BSMTP input.
2007-03-10 06:47:34 1HPuLd-0003hL-00 <user.anti-spam@m...et>:
D=spamcheck_director T=spamcheck: Child process of spamcheck transport
returned 2 from command: /usr/sbin/exim
Les messages d'erreurs renvoyés à l'expediteur par exim sont comme suit:
********
Child process of spamcheck transport returned 2 from command:
/usr/sbin/exim
An error was detected while processing a file of BSMTP input.
The error message was:
554 Unexpected end of file
The SMTP transaction started in line 0.
The error was detected in line 3.
0 previous messages were successfully processed.
The rest of the batch was abandoned.
554 Unexpected end of file
Transaction started in line 0
Error detected in line 3
------ This is a copy of the message, including all the headers. ------
Return-path: <root@mon.domaine>
Received: from expourri.rebelles ([192.168.1.247]
helo=localhost.localdomain) by alf94-3-82-66-248-156.fbx.proxad.net
with esmtp (Exim 3.35 #1 (Debian)) id 1HPx8M-0004Rb-00
for <francois@mon.domaine>; Sat, 10 Mar 2007 09:40:58 +0100
Received: from root by localhost.localdomain with local (Exim 4.50)
id 1HPx8S-00017N-HT
for root@localhost.localdomain; Sat, 10 Mar 2007 09:41:04 +0100
From: Anacron <root@mon.domaine>
To: root@localhost.localdomain
Subject: Anacron job 'cron.daily' on expourri
Message-Id: <E1HPx8S-00017N-HT@localhost.localdomain>
Date: Sat, 10 Mar 2007 09:41:04 +0100
X-Scanner: exiscan *1HPx8M-0004Rb-00*.xZ5GWDNhaM*
/etc/cron.daily/lprng:
*****************
J'ai mis le message complet car je ne comprends pas ce qu'est cette
fameuse ligne 3.
La directive exim (exim 3 de sarge) est la suivante:
spamcheck:
driver = pipe
command = /usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr \
spam-scanned -bS
(une seule ligne) suivant les idées du seul message un peu précis
trouvé sur Google à ce sujet (à savoir
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060206/msg00196.html
)
mais cela m'a donné une erreur du même type disant
********
[..]
an error was detected while processing a file of BSMTP input.
The error message was:
500 Command unrecognized
The SMTP transaction started in line 0.
The error was detected in line 1.
The SMTP command at fault was:
X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on
0 previous messages were successfully processed.
The rest of the batch was abandoned.
500 Command unrecognized
Transaction started in line 0
Error detected in line 1
[..]
***************
erreur que je ne comprends pas, exim devrait prendre la sortie directe
et la traiter. Or il semble prendre l'entrée comme un fichier de
commandes.
Bref, je patauges un peu. Si les courageux (que je remercie) qui ont lu
ce message jusque là (et qui vont le terminer, le plus dur est fait!)
ont une idée, je suis preneur. En attendant, comme il semble que ça
*serait* un problème de timeout, j'ai rajouté une option -t 300 à
l'appel de spamc.
Le pbm est que je n'ai pas une idée clair de ces directives (entre
autres bsmtp=all fait quoi?)
Merci de toutes réponses
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
François Boisson
> J'ai essayé de remplacer cela par
spamcheck: driver = pipe command = /usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr spam-scanned -bS (une seule ligne) suivant les idées du seul message un peu précis trouvé sur Google à ce sujet (à savoir http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060206/msg00196.html )
Avec cela il n'y a plus d'erreur, la directive bsmtp est une directive donnant un format «batched smtp format» à la sortie de spamc.
J'ignore si cette rustine va fonctionner et suis toujours intéressé par des suggestions.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
> J'ai essayé de remplacer cela par
spamcheck:
driver = pipe
command = /usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr
spam-scanned -bS
(une seule ligne) suivant les idées du seul message un peu précis
trouvé sur Google à ce sujet (à savoir
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060206/msg00196.html
)
Avec cela il n'y a plus d'erreur, la directive bsmtp est une directive
donnant un format «batched smtp format» à la sortie de spamc.
J'ignore si cette rustine va fonctionner et suis toujours intéressé par
des suggestions.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
spamcheck: driver = pipe command = /usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr spam-scanned -bS (une seule ligne) suivant les idées du seul message un peu précis trouvé sur Google à ce sujet (à savoir http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060206/msg00196.html )
Avec cela il n'y a plus d'erreur, la directive bsmtp est une directive donnant un format «batched smtp format» à la sortie de spamc.
J'ignore si cette rustine va fonctionner et suis toujours intéressé par des suggestions.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Marche pas lorsque l'adresse du destinataire n'est pas dans les entêtes du message :(. Retour à la case départ.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Marche pas lorsque l'adresse du destinataire n'est pas dans les entêtes
du message :(. Retour à la case départ.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Marche pas lorsque l'adresse du destinataire n'est pas dans les entêtes du message :(. Retour à la case départ.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
Le Sat, 10 Mar 2007 17:53:47 +0100 François Boisson a écrit: [..]
Suite pour ce qui suivent (merci à eux).
Le problème semblent précis: Pour des raisons encore floues, le démon spamd gèle dans le traitement d'un message. Exim est assez impatient dans le traitement d'un transport, si le retour n'a pas lieu vite, il sort cette fameuse erreur 2.
Une rustine indispensable pour ne pas perdre du courier consiste à donner à spamc un timeout serré de 60s (en gros le traitement d'un mail prend 10s), cela se fait par la directive command = /usr/sbin/exim -oMr spam-scanned -bS transport_filter = /usr/bin/spamc -t 60 -p 780 (rajout du «-t 60»).
De même, il est raisonnable de lancer spamd avec une option --timeout-childY afin d'avoir un timeout de spamd.
Dans ces conditions, il n'y a plus de mails perdus. Par contre, lors du déclenchemenbt du timeout, les maisl ne sont pas filtrés et les spams passent.
Pour les raisons, j'ai noté dans les logs de spamssassin (spamd avec -D) deux choses:
1) auto-whitelist: open of auto-whitelist file failed: auto-whitelist: cannot open auto_whitelist_path /var/mail/.spamassassin/auto-whitelist: Ioctl() inappropré pour un périphérique
le path est bon, je ne comprends pas l'erreur. Bon, j'ai viré le recours à la whitelist.
2) Des messages bayes: expire_old_tokens: child processing timeout at /usr/sbin/spamd line 1085. qui semblent correspondre au moment du gel.
Dans le doute, j'ai donc refait complètement la base bayes. Celle ci provenait d'une version de spamassassin 2.6?? converti par sa-learn. Quelqu'un a-t-il eu des pbms dans des conditions similairees?
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Sat, 10 Mar 2007 17:53:47 +0100
François Boisson <user.anti-spam@maison.homelinux.net> a écrit:
[..]
Suite pour ce qui suivent (merci à eux).
Le problème semblent précis: Pour des raisons encore floues, le démon
spamd gèle dans le traitement d'un message. Exim est assez impatient
dans le traitement d'un transport, si le retour n'a pas lieu vite, il
sort cette fameuse erreur 2.
Une rustine indispensable pour ne pas perdre du courier consiste à
donner à spamc un timeout serré de 60s (en gros le traitement d'un mail
prend 10s), cela se fait par la directive
command = /usr/sbin/exim -oMr spam-scanned -bS
transport_filter = /usr/bin/spamc -t 60 -p 780
(rajout du «-t 60»).
De même, il est raisonnable de lancer spamd avec une option
--timeout-childY
afin d'avoir un timeout de spamd.
Dans ces conditions, il n'y a plus de mails perdus. Par contre, lors du
déclenchemenbt du timeout, les maisl ne sont pas filtrés et les spams
passent.
Pour les raisons, j'ai noté dans les logs de spamssassin (spamd avec
-D) deux choses:
1)
auto-whitelist: open of auto-whitelist file failed: auto-whitelist:
cannot open auto_whitelist_path /var/mail/.spamassassin/auto-whitelist:
Ioctl() inappropré pour un périphérique
le path est bon, je ne comprends pas l'erreur. Bon, j'ai viré le
recours à la whitelist.
2) Des messages
bayes: expire_old_tokens: child processing timeout at /usr/sbin/spamd
line 1085.
qui semblent correspondre au moment du gel.
Dans le doute, j'ai donc refait complètement la base bayes. Celle ci
provenait d'une version de spamassassin 2.6?? converti par sa-learn.
Quelqu'un a-t-il eu des pbms dans des conditions similairees?
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Sat, 10 Mar 2007 17:53:47 +0100 François Boisson a écrit: [..]
Suite pour ce qui suivent (merci à eux).
Le problème semblent précis: Pour des raisons encore floues, le démon spamd gèle dans le traitement d'un message. Exim est assez impatient dans le traitement d'un transport, si le retour n'a pas lieu vite, il sort cette fameuse erreur 2.
Une rustine indispensable pour ne pas perdre du courier consiste à donner à spamc un timeout serré de 60s (en gros le traitement d'un mail prend 10s), cela se fait par la directive command = /usr/sbin/exim -oMr spam-scanned -bS transport_filter = /usr/bin/spamc -t 60 -p 780 (rajout du «-t 60»).
De même, il est raisonnable de lancer spamd avec une option --timeout-childY afin d'avoir un timeout de spamd.
Dans ces conditions, il n'y a plus de mails perdus. Par contre, lors du déclenchemenbt du timeout, les maisl ne sont pas filtrés et les spams passent.
Pour les raisons, j'ai noté dans les logs de spamssassin (spamd avec -D) deux choses:
1) auto-whitelist: open of auto-whitelist file failed: auto-whitelist: cannot open auto_whitelist_path /var/mail/.spamassassin/auto-whitelist: Ioctl() inappropré pour un périphérique
le path est bon, je ne comprends pas l'erreur. Bon, j'ai viré le recours à la whitelist.
2) Des messages bayes: expire_old_tokens: child processing timeout at /usr/sbin/spamd line 1085. qui semblent correspondre au moment du gel.
Dans le doute, j'ai donc refait complètement la base bayes. Celle ci provenait d'une version de spamassassin 2.6?? converti par sa-learn. Quelqu'un a-t-il eu des pbms dans des conditions similairees?
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
Bon, cette fois c'est complètement résolu et ça n'est pas exim.
C'est le bug 4950 de spassassin http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on peut résoudre en mettant l'option «--round-robin» dans les options de lancement de spamassassin. C'est en problème dans le fork des spamd fils apparu avec la version sarge de spamassassin, les réglages
spamc appelé avec une option -t 60 et spamd avec l'option --timeout-child`
m'ont permis de ne plus perdre de mails. En trouvantun mail qui avait rencontrer le problème et l'heure précise ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont montré dans mail.info (et là seulement)
Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687 failed on try 4 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610. Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612. Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to 7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 343. Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child 7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 137. Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]: prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]: prefork: select returned -1! recovering: Mauvais descripteur de fichier Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32 cerbere last message repeated 30 times
Une recherche là dessus plus un épluchage des sources de SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd m'ont conduit à la solution. Celle ci est confirmé dans http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!, ça aura mis 15 jours...
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bon, cette fois c'est complètement résolu et ça n'est pas exim.
C'est le bug 4950 de spassassin
http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on
peut résoudre en mettant l'option «--round-robin» dans les options de
lancement de spamassassin. C'est en problème dans le fork des spamd
fils apparu avec la version sarge de spamassassin, les réglages
spamc appelé avec une option -t 60 et
spamd avec l'option --timeout-child`
m'ont permis de ne plus perdre de mails.
En trouvantun mail qui avait rencontrer le problème et l'heure précise
ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont
montré dans mail.info (et là seulement)
Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687
failed on try 4
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to
7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 343.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child
7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 137.
Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup
of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]:
prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]:
prefork: select returned -1! recovering: Mauvais descripteur de fichier
Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32
cerbere last message repeated 30 times
Une recherche là dessus plus un épluchage des sources de
SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd
m'ont conduit à la solution. Celle ci est confirmé dans
http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!,
ça aura mis 15 jours...
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Bon, cette fois c'est complètement résolu et ça n'est pas exim.
C'est le bug 4950 de spassassin http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on peut résoudre en mettant l'option «--round-robin» dans les options de lancement de spamassassin. C'est en problème dans le fork des spamd fils apparu avec la version sarge de spamassassin, les réglages
spamc appelé avec une option -t 60 et spamd avec l'option --timeout-child`
m'ont permis de ne plus perdre de mails. En trouvantun mail qui avait rencontrer le problème et l'heure précise ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont montré dans mail.info (et là seulement)
Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687 failed on try 4 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610. Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612. Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to 7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 343. Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child 7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 137. Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]: prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]: prefork: select returned -1! recovering: Mauvais descripteur de fichier Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32 cerbere last message repeated 30 times
Une recherche là dessus plus un épluchage des sources de SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd m'ont conduit à la solution. Celle ci est confirmé dans http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!, ça aura mis 15 jours...
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Patrice OLIVER
Merci François pour cette information qui sera prévieuse à ceux d'entre nous dont je fais partie qui utilisent spamassassin.
Bonne journée. :)
Patrice.
Le 18/03/07, François Boisson a éc rit :
Bon, cette fois c'est complètement résolu et ça n'est pas exim.
C'est le bug 4950 de spassassin http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on peut résoudre en mettant l'option «--round-robin» dans les options de lancement de spamassassin. C'est en problème dans le fork des spamd fils apparu avec la version sarge de spamassassin, les réglages
spamc appelé avec une option -t 60 et spamd avec l'option --timeout-child`
m'ont permis de ne plus perdre de mails. En trouvantun mail qui avait rencontrer le problème et l'heure précis e ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont montré dans mail.info (et là seulement)
Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687 failed on try 4 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610. Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612. Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to 7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 343. Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child 7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 137. Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]: prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]: prefork: select returned -1! recovering: Mauvais descripteur de fichier Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32 cerbere last message repeated 30 times
Une recherche là dessus plus un épluchage des sources de SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd m'ont conduit à la solution. Celle ci est confirmé dans http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!, ça aura mis 15 jours...
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact .org
Merci François pour cette information qui sera prévieuse à ceux
d'entre nous dont je fais partie qui utilisent spamassassin.
Bonne journée.
:)
Patrice.
Le 18/03/07, François Boisson<user.anti-spam@maison.homelinux.net> a éc rit :
Bon, cette fois c'est complètement résolu et ça n'est pas exim.
C'est le bug 4950 de spassassin
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4590 que l'on
peut résoudre en mettant l'option «--round-robin» dans les options de
lancement de spamassassin. C'est en problème dans le fork des spamd
fils apparu avec la version sarge de spamassassin, les réglages
spamc appelé avec une option -t 60 et
spamd avec l'option --timeout-child=60
m'ont permis de ne plus perdre de mails.
En trouvantun mail qui avait rencontrer le problème et l'heure précis e
ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont
montré dans mail.info (et là seulement)
Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687
failed on try 4
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to
7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 343.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child
7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 137.
Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup
of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]:
prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]:
prefork: select returned -1! recovering: Mauvais descripteur de fichier
Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32
cerbere last message repeated 30 times
Une recherche là dessus plus un épluchage des sources de
SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd
m'ont conduit à la solution. Celle ci est confirmé dans
http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!,
ça aura mis 15 jours...
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian .org
Merci François pour cette information qui sera prévieuse à ceux d'entre nous dont je fais partie qui utilisent spamassassin.
Bonne journée. :)
Patrice.
Le 18/03/07, François Boisson a éc rit :
Bon, cette fois c'est complètement résolu et ça n'est pas exim.
C'est le bug 4950 de spassassin http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on peut résoudre en mettant l'option «--round-robin» dans les options de lancement de spamassassin. C'est en problème dans le fork des spamd fils apparu avec la version sarge de spamassassin, les réglages
spamc appelé avec une option -t 60 et spamd avec l'option --timeout-child`
m'ont permis de ne plus perdre de mails. En trouvantun mail qui avait rencontrer le problème et l'heure précis e ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont montré dans mail.info (et là seulement)
Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687 failed on try 4 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610. Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612. Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to 7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 343. Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child 7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 137. Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]: prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]: prefork: select returned -1! recovering: Mauvais descripteur de fichier Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32 cerbere last message repeated 30 times
Une recherche là dessus plus un épluchage des sources de SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd m'ont conduit à la solution. Celle ci est confirmé dans http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!, ça aura mis 15 jours...
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact .org
François Boisson
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` --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
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
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`
--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
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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` --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
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
