-----Original Message-----
From: procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
[mailto:procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE]On Behalf Of
Professional
Software Engineering
Sent: Monday, February 02, 2004 1:09 PM
At 11:08 2004-02-02 -0800, R A Lichtensteiger wrote:
[snip]
First question is whether "spamc" even needs a lock file -- does it
write to any files (including a spam/ham database) or does it simply
add headers to the message (I don't use spamassasin so I have no idea
what it does in regard to file accesses etc.)
Importantly isn't whether spamc simply writes to files, but
whether itself
writes to files without performing its own file locking - as long
as spamc
does it's own locking, there is no need for procmail to add another level
of locking to the mix, though having a procmail lockfile before invoking
spamc can help to keep spamc load down, you still end up with a bunch of
procmail processes waiting around.
I'd be surprised if spamc doesn't perform it's own locking on any files
which it writes to. Since source is available, you should be
able to just
examine it looking for where it writes to files.
spamc is a small client that connects to the Spamassassin deamon,
called spamd. Spamd has some configuration variables that can be set
to tell it the maximum number of helper processes to spawn. Each
helper process is fed one message at a time. Generally, spamassassin
is CPU bound because it reads in the mail message and runs many, many
Perl regular expressions and subroutines over the message to look for
signs of spam.
- it is important to not set the max. children variable used by spamd
too high, because virtual memory thrashing can occur. There's a lot
of info at http://www.spamassassin.org and related Wiki, and other
resources, linked from there which offer tips for tuning.
- if your procmail script calls spamassassin (not spamc) directly, you
might want to consider serializing that call as a way of modulating system
load. Spamassassin often has a big cpu and memory footprint, and since
there's no spamd doing the load balancing for you, it can be helpful to
serialize things in your procmailrc script, _if_ you call _spamassassin_
(_not_ spamc) directly.
- one of the main reasons that spamc will appear to 'hang' is that it has
asked spamd to run its filters, and those filters invoke "network tests"
which do things like connect to "real time black lists", otherwise known
as RBL's and DNSBL's. Those network servers can become busy, unavaialable
and so on. There are some tips on how to set timeouts, and which RBL's are
are having problems, have gone off-line, etc. at the Spamassassin.org site
listed above.
- Finally, you might want to try starting up spamd with debugging logging
enabled to see what's going on, where the problems are cropping up. Also,
the spassassin mailling list (and archives) can be a helpful resource,
http://eu.spamassassin.org/lists.html
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail