> I'm curious as to how one might limit the number of simultaneous > spamassassin processes.
This is one idea that surfaced while reading your question. I am sure there are better ones. > I run spamassassin as a procmail filter. If you are using the typical .procmailrc rule to pipe through to spamassassin then typically it would look like this: :0fw | spamassassin -P That does not use any lockfile. Therefore processes are allowed to run in parallel. But 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. This may be enough to solve your problem sufficiently. :0fw:spamassassin-run.lock | spamassassin -P > 1. I type `fetchmail'. Fetchmail starts downloading ~50 messages. There probably is a fetchmail configuration to run things sequentially instead of in parallel. I don't know fetchmail but would prefer that configuration if I did. Possibly there is a configuration to tell sendmail to 'queue' the mail intead of acting upon it immediately. Then after all of the mail has been queued I would run 'sendmail -q' to run the queue. That will all be done from one sendmail process and everything should behave reasonably. This would be a good choice if possible. > 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. > Or is there a switch to flip to make procmail or sendmail process > the mail serially -- not by re-queuing it, but by using some form of > locking such that when one spamassassin terminates, another is > immediately started? Check out the procmail lockfile synchronization and see if that solves the problem. Bob
msg07054/pgp00000.pgp
Description: PGP signature
