>>>>> "BS" == Bart Schaefer <[EMAIL PROTECTED]> writes:
BS> On Fri, 5 Jul 2002, Bob Proulx wrote:
>> > I run spamassassin as a procmail filter.
>>
>> [...] if you did use a lockfile here then while sendmail would
>> run in parallel and procmail would run in parallel they would
>> converge at the spamassassin step and only one of those would
>> be running at a time.
>>
>> :0fw:spamassassin-run.lock | spamassassin -P
BS> Right idea, wrong execution. Local lockfiles are ignored on
BS> recipes that do not deliver to files. You need a global
BS> lockfile when delivering to a pipe, like this:
BS> LOCKFILE=spamassassin-run.lock :0fw | spamassassin -P
BS> LOCKFILE
>> > Would spamc/spamd respond better to an inrush of mail?
>>
>> I do not use it myself. But that is what it was designed to
>> do. One process to do the work and be lighter on the use of
>> system resources.
BS> Spamd forks on each connection, so this won't lighten the load
BS> unless you use the -m option to limit the number of forked
BS> copies. I use -m 3 on a P233 with 128MB and that seems to
BS> deal with fetchmail floods just fine. On the other hand I
BS> don't usually have more than 15 or 20 messages waiting at a
BS> time.
BS> You do end up with a lot of copies of procmail and spamc
BS> blocked waiting for another spamd to become available, but at
BS> least they don't all try to run at once.
Chris Nestrud <[EMAIL PROTECTED]> suggested using fetchmail's MDA option
to pass the messages to procmail directly ( mda "/usr/bin/procmail -d
%s"). Fetchmail processes the messages serially, so the system doesn't
get wedged under a mob of spamassassin processes.
This does mean that the messages take much longer to process, as each
message must wait for perl to start and SA to run. I'll try the -m
option to spamd to run a limited number of SAs in in parallel.
--Joe
msg07089/pgp00000.pgp
Description: PGP signature
