On Mon, 12 Mar 2007, maillist wrote:
Michał Jęczalik wrote:
Hello,
after upgrading from 3.1.7 I have numerous problems with my spamd. It hangs
up during high load and become permamently unresponsive. According to
advices I have found on devel list, I'm using --round-robin now and it
hangs less often. But now I have a lot of
~/.spamassassin/bayes_toks.expire[pid] lockfiles, that don't disappear and
quickly foul user's quota. It's interesting that on another host with
similar load conditions everything works ok. Anyway - am I the only one
experiencing these problems? There's no rumour on the devel list, there's
no rumour here - what's wrong? :) In this situation 3.1.8 is quite unusable
for me and I'm thinking about downgrade. The only reason I have not done it
already is that I'm not sure if this is a simple task - my users won't
stand another spamassassin blackout, after numerous spam floods due to
those hang-ups in past couple of days. ;-)
How did you upgrade?
perl Makefile.PL etc ;-)
What OS?
Linux 2.4
What MDA?
It is completly unrelated to MDA. I invoke spamd with inetd and spamc with
procmail, but the problem is in spamd itself. Probably one could repeat it
with feeding messages manually to spamc. As far as I read the devel
list, guys out there are aware of this problem, but they seem to be
satisfied with the temporary (?) solution of --round-robin so far. But it
doesn't fix the problem, it just seems to decrease intensivity.
Oh, I've just noticed it died again. Well, killall spamd... ;-)
When you say "hangs" what do you mean?
This is what I mean:
5707 ? Ss 0:02 /usr/bin/perl -T -w /usr/bin/spamd --max-children=14
--round-robin
5805 ? R 58:05 spamd child
5826 ? S 3:10 spamd child
5851 ? R 31:03 spamd child
5862 ? R 26:19 spamd child
5873 ? R 26:11 spamd child
5882 ? R 26:09 spamd child
15341 ? R 18:15 spamd child
17651 ? R 16:09 spamd child
22972 ? R 16:16 spamd child
9744 ? R 10:47 spamd child
14581 ? S 1:37 spamd child
18379 ? R 10:18 spamd child
21493 ? R 7:21 spamd child
24789 ? R 6:43 spamd child
And a nice bunch of spamc - some probably hung up waiting for output from
spamd, and some continously trying to connect and feed incoming mails (and
giving up after some retries, passing the message spam-uncredited).
A last sane response of every spamd's child is "processing message ...".
--
Michał Jęczalik, +48.603.64.62.97
INFONAUTIC, +48.33.487.69.04
