[Aaron has directed replies to the list, so I'm gladly cooperating.]
| I work at a mid-size ISP, where we use procmail as our local delivery
| agent. We often have situations where there are lots of procmail
| processes running for one user waiting for a lock on the user's
| mailfile. We're thinking about modifying procmail to return a
| temporary failure in many of these cases, so that sendmail will just
| requeue the message.
|
| Our plan is to create a new special variable that would indicate if it
| was safe to do this. It would start out set to "y", but be unset
| whenever a delivery was made, or whenever a program (other than a few
| exceptions like "date") was run. Then if it couldn't get the lock
| after a short timeout, it would return a temporary failure.
|
| Does anyone have any thoughts on this? Do you think it's a bad idea,
| or are there other things that we should watch out for?
It seems to me that if there are many processes trying to deliver to one
user's spool file at once, that user probably doesn't have a .procmailrc
[otherwise he or she would most likely be sprinkling incoming mail among
assorted folders], so I tend to think that some code in /etc/procmailrc will
do the job just as well as modifying procmail.
Lockfile(1) has no way to specify how long to keep trying before giving up;
you can specify how many times to try for the lock before giving up and how
long to wait between tries, and you can specify how long to keep trying
before stealing the lock. So I'm wondering if this won't do the job in
/etc/procmailrc:
DROPPRIVS=yes
TIMES_TO_TRY=10 # or whatever number you select
:0
* $ $TIMES_TO_TRY^0
* -1^0
{ NUMBER_OF_RETRIES = $= }
:0
* ! ? test -r $HOME/.procmailrc
* ! ? lockfile -r $NUMBER_OF_RETRIES -ml
{
# Do whatever it takes to requeue a message on your system:
EXITCODE=75
HOST
# Since the lockfile was never created, it needn't be removed.
}