Timothy J Luoma <luomat+procmail(_at_)luomat(_dot_)peak(_dot_)org> writes (back
in October):
Twice in the last few days I have had serious mail problems.
It stemmed from the fact that sendmail was not running for several hours,
and then a lot of mail tried to download at the same time.
I would see things like this:
procmail: Failed forking "formail"
procmail: Rescue of unfiltered data succeeded
/bin/sh: fork failed - too many processes
Why is procmail forking so much?
Unless you have a pile of cloning blocks, this is not procmail's fault:
except for cloning blocks, the subprocesses that procmail forks off only
last for one recipe, so it's not like procmail is forking off a hug
number of processes that are clogging your process table.
Is it the amount of messages being processed at once? If so, how can I
limit this?
sendmail has two options that control the loadaverages at which it
a) stops attempting delivery and just queues messages, and
b) stops accepting mail via SMTP.
You really can't just limit the number of simultaneous deliveries.
I use a global lockfile on my .procmailrc -- could that be making it worse?
Yes. There could be a dozen procmails all wanting to deliver mail to
you, held up by this global lockfile. A global lockfile doesn't mean
only one procmail process will be running for you: it means only one
procmail process can be processing that section of your .procmailrc.
The others will be sitting at that LOCKFILE assignment waiting for it
to disappear. Fine-grained serialization (i.e., locallockfiles) are a
Good Thing.
(Is there a way to adjust sendmail to help alleviate this problem?)
Not really. Lowering the load average at which it stops attempting
delivery may help some, but that's pretty drastic, and won't really
work that well: procmail processes waiting on lockfiles don't consume
much CPU. Removing the global lockfile is a much better choice.
Philip Guenther