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
Right idea, wrong execution. Local lockfiles are ignored on recipes that
do not deliver to files. You need a global lockfile when delivering to a
pipe, like this:
LOCKFILE=spamassassin-run.lock
:0fw
| spamassassin -P
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.
Spamd forks on each connection, so this won't lighten the load unless you
use the -m option to limit the number of forked copies. I use -m 3 on a
P233 with 128MB and that seems to deal with fetchmail floods just fine. On
the other hand I don't usually have more than 15 or 20 messages waiting at
a time.
You do end up with a lot of copies of procmail and spamc blocked waiting
for another spamd to become available, but at least they don't all try to
run at once.
> > Or is there a switch to flip to make procmail or sendmail process
> > the mail serially
Sendmail has an option to queue up messages when the load average exceeds
a specified value; you can try that as well.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
