OVH Cloud OVH Cloud

[spamassassin] swap_duplicate at c011acf1: entry 00062b00, unused page

4 réponses
Avatar
Etienne de Tocqueville
Bonjour,

Je lance spamassassin en deamon ("spamd -d -c -a -m 2 -D" lancé au
boot), et régulièrement, au bout de quelque jours, il cesse de me
filtrer mes messages.


Je teste avec un spam donné qui est bien détecté par spamassassin :

$ cat Mail/gnus/inbox/5755 | spamassassin -t | grep ^X-Spam
X-Spam-Status: Yes, hits=11.0 required=5.0
X-Spam-Flag: YES
X-Spam-Level: ***********
X-Spam-Checker-Version: SpamAssassin 2.31 (devel $Id: SpamAssassin.pm,v 1.94.2.2 2002/06/20 17:20:29 hughescr Exp $)
X-Spam-Prev-Content-Type: text/html; charset=iso-8859-1
X-Spam-Prev-Content-Transfer-Encoding: 8bit


Mais si j'utilise le client spamc du deamon spamd, ça ne passe pas :

$ cat Mail/gnus/inbox/5755 | spamc | grep ^X-Spam
[ rien n'est retourné : pas d'entete X-Spam dans le résultat ]


Et dans /var/log/messages (j'ai mis -D au deamon), j'ai :

Dec 9 19:14:03 steph kernel: swap_duplicate at c011acf1: entry 00062b00, unused page
Dec 9 19:14:03 steph kernel: swap_duplicate at c012347c: entry 00062b00, unused page
Dec 9 19:14:03 steph kernel: VM: killing process spamd
Dec 9 19:14:03 steph kernel: swap_free: swap-space map bad (entry 00062b00)


Le process spamd tourne bien sur pourtant toujours (sinon il n'y auraot
pas de logs) :

$ ps -fp 822
UID PID PPID C STIME TTY TIME CMD
root 822 1 0 Dec07 ? 00:00:10 perl /usr/bin/spamd -d -c -a -m

J'utilise SpamAssassin version 2.31 sur linux 2.2.16 (RH)

C'est assez casse pied, parce que quand ça tombe (1 fois tous les 3 ou 4
jours) je me reçois pleins de spams ! Quelqu'un a-t-il une idée de où ca
vient, ou vers où chercher ?...

Merci d'avance !
Etienne

4 réponses

Avatar
Stephane Dupille
Bonjour,


Salut !

Je lance spamassassin en deamon ("spamd -d -c -a -m 2 -D" lancé au
boot), et régulièrement, au bout de quelque jours, il cesse de me
filtrer mes messages.


Ah ?

< snip >

Et dans /var/log/messages (j'ai mis -D au deamon), j'ai :
Dec 9 19:14:03 steph kernel: swap_duplicate at c011acf1: entry 00062b00, unused page
Dec 9 19:14:03 steph kernel: swap_duplicate at c012347c: entry 00062b00, unused page
Dec 9 19:14:03 steph kernel: VM: killing process spamd
Dec 9 19:14:03 steph kernel: swap_free: swap-space map bad (entry 00062b00)


Ce sont des messages du kernel, pas des messages de spamd. Il dit
simplement qu'il a tué spamd. A priori, tu aurais des problèmes de
mémoire, et la swap aurait quelques problèmes.

D'abord, avant qu'il ne plante, regarde combien bouffe de mémoire
spamd. Surtout, regarde si cette consommation de mémoire est stable,
ou s'il y aurait un memory leak.

Regarde aussi quels process sont mis en swap. Il semblerait que le
kernel ait quelques problèmes avec la gestion de sa swap. Je
suspecterait des blocs défectueux du disque, dans la partoche du swap,
ou des problèmes avec les barrettes de mémoire.

Le process spamd tourne bien sur pourtant toujours (sinon il n'y auraot
pas de logs) :


Non, les messages que tu vois sont envoyés par le kernel, et sont
collectés par syslog. Spamd peut très bien ne pas tourner et tu
aurais ces messages quand même.

$ ps -fp 822
UID PID PPID C STIME TTY TIME CMD
root 822 1 0 Dec07 ? 00:00:10 perl /usr/bin/spamd -d -c -a -m


Le process est là, mais il ne tourne plus. Il est mort quoi, c'est
étonnant qu'on le voit encore.

J'utilise SpamAssassin version 2.31 sur linux 2.2.16 (RH)
C'est assez casse pied, parce que quand ça tombe (1 fois tous les 3 ou 4
jours) je me reçois pleins de spams ! Quelqu'un a-t-il une idée de où ca
vient, ou vers où chercher ?...


Le problème ne vient pas de spamassassin (du moins je pense). Le
problème vient du kernel. Je regarderais les badblocks sur les
partoches de swap, pour commencer. Je testerais par ailleurs la
mémoire (avec memtest86 par exemple). Je ferais une mise à jour du
kernel, aussi, par ailleurs (parce que ça sent gros le bug du kernel).

Merci d'avance !


De rien. HTH.

--
BC> les règles (évitez le terme de lois qui est seulement juridique)
Comme la loi de la pesanteur et celle de l'emmerdement maximum, deux
lois dont vous représentez la synthèse : vous êtes lourd et chiant.
-+- FF in http://www.le-gnu.net : Dura crétinex sed neuneutex.

Avatar
Etienne de Tocqueville
"Stephane Dupille" <sdupille+ a écrit sur fr.comp.os.unix :

D'abord, avant qu'il ne plante, regarde combien bouffe de mémoire
spamd. Surtout, regarde si cette consommation de mémoire est stable,
ou s'il y aurait un memory leak.


Bon ben c'est bien sur quand on surveille que ça plante plus ! ;-)

Regarde aussi quels process sont mis en swap. Il semblerait que le
kernel ait quelques problèmes avec la gestion de sa swap. Je
suspecterait des blocs défectueux du disque, dans la partoche du swap,
ou des problèmes avec les barrettes de mémoire.


Les process qui sont mis en swap, c'est bien ceux qui ne sont plus
utilisé depuis un moment... Je ne vois rien d'anormal de ce coté là...

$ ps -fp 822
UID PID PPID C STIME TTY TIME CMD
root 822 1 0 Dec07 ? 00:00:10 perl /usr/bin/spamd -d -c -a -m


Le process est là, mais il ne tourne plus. Il est mort quoi, c'est
étonnant qu'on le voit encore.


Pas tout a fait mort quand meme... Au premier abord, il écoutait quand
meme sur le port. Pendant le test dont je parlais dans mon précédent
article, j'avais dans le /var/log/maillog :

Dec 9 19:14:03 steph spamd[822]: connection from localhost.localdomain [ 127.0.0.1 ] at port 1328
Dec 9 19:14:03 steph spamd[822]: logmsg: connection from localhost.localdomain [ 127.0.0.1 ] at port 1328
Dec 9 19:14:03 steph spamd[25024]: info: setuid to etienne succeeded
Dec 9 19:14:03 steph spamd[25024]: logmsg: info: setuid to etienne succeeded

Le problème ne vient pas de spamassassin (du moins je pense). Le
problème vient du kernel. Je regarderais les badblocks sur les
partoches de swap, pour commencer.


Je sais pas trop comment on regarde ça, mais je vais chercher ! Le fsck
ne m'a en tout cas jamais rien dit qui m'ait semblé catastrophique...

Je testerais par ailleurs la mémoire (avec memtest86 par exemple).


Je viens de télécharger l'engin, mais c'est pas simple a faire
fonctionner : il faut booter sur une disquette, donc il faut que sorte
la machine du placard, et que je trouve un écran et un clavier ;-) Mais
c'est une bonne idée ! Je ferais ce test

Je ferais une mise à jour du
kernel, aussi, par ailleurs (parce que ça sent gros le bug du kernel).


Bof... Je vois pas trop pourquoi le noyau serait brutalement buggé alors
que je l'utilise depuis bien 2 ans, et que spamassassin tourne depuis 6
mois. Mes problèmes n'ont commencé que depuis quelques semaines

Mais en meme temps que les arrets intempestifs de spamassassin, j'ai
aussi eu des plantages de innd, et meme récemment un truc très bizarre :
après un plantage complet de ma bécane, je n'ai pas pu rebooter à cause
de mon fichier inittab qui s'est retrouvé avec une taille de "-1" (dikit mon
"ls -l")... Très étrange...

Merci en tout cas pour toutes ces pistes !

Etienne


Avatar
Stephane Le Men
Etienne de Tocqueville <et+ wrote:

Je ferais une mise à jour du
kernel, aussi, par ailleurs (parce que ça sent gros le bug du kernel).


Bof... Je vois pas trop pourquoi le noyau serait brutalement buggé alors
que je l'utilise depuis bien 2 ans, et que spamassassin tourne depuis 6
mois. Mes problèmes n'ont commencé que depuis quelques semaines


sniff sniff, hummmm. Ca pue le pb hard.

Mais en meme temps que les arrets intempestifs de spamassassin, j'ai
aussi eu des plantages de innd, et meme récemment un truc très bizarre :
après un plantage complet de ma bécane, je n'ai pas pu rebooter à cause
de mon fichier inittab qui s'est retrouvé avec une taille de "-1" (dikit mon
"ls -l")... Très étrange...


Ca pue vraiment tres fort le pb hard. Pour un test, deactive l'utilisation
de ton cache L2, et change lui ses barrettes si elle s'entete.

Ces chiasses de PC n'ont pas tous un parity check sur le L2, et ce genre
de problemes font de gros bobos aux kernels.


Avatar
Etienne de Tocqueville
Stephane Le Men a écrit sur fr.comp.os.unix :

Ca pue vraiment tres fort le pb hard. Pour un test, deactive l'utilisation
de ton cache L2, et change lui ses barrettes si elle s'entete.


Ah oui ? Je ne connaissais pas cette histoire de cache L2... D'après la
littérature que je viens de lire, ça à l'air de ce changer au boot, tout
ça ? Bon, entre ça et le memtest86, va vraiment valloir que j'y mette un
clavier et que je la reboot, ma machine ! ;-)

Merci en tout cas pour cette piste ! Je l'appliquerais sous peu, et je
reviendrais si ça ne marche pas ! :-)