"Dr. Elmar Schaetzlein" <Elmar(_dot_)Schaetzlein(_at_)mch(_dot_)sni(_dot_)de>
I'm new in using procmail, so sorry if this is a typical FAQ.
In my logfile I get very often messages as
procmail: Deadlock attempted on "/home2/sch/.lockmail"
Deadlock (in the simplest case) occurs when a program is holding a
lockfile, and tries to lock it again. It can't do so, because the
file is locked (by itself), and so would hang forever. Procmail is
smart enough to notice this and avoid the hang. Deadlock can also
occur between multiple processes, but that isn't what's happening here.
/home2/sch/.lockmail ist my lockfile (see the beginning of
my .procmailrc below):
This is your problem. You shouldn't be using a global lockfile, but
rather per-recipe 'local' lockfiles. For all the hundreds of procmail
recipes that I've read and written, only a couple need a global
lockfile, and this isn't one of them.
Delete this line.
| tee /home2/sch/lockslist | mailx -s LOCKSLIST sch
When you assigned to LOCKFILE earlier, you told procmail to wait until
$HOME/.lockmail _doesn't_ exist, then create it. Now you're telling
procmail to do that again, when it still hasn't removed the one it
created with the assignment to LOCKFILE. <poof> Instant deadlock.
The other thing you should keep in mind is that the name of the
lockfile in use should be related to the name of the file(s) be written
to. Normally you take the name of the file and add $LOCKEXT, which
is ".lock", so that the above recipe should be written:
|tee $HOME/lockslist | mailx -s LOCKSLIST sch
| tee -a $DEFAULT | mailx -s SNI-Mail
This should be rewritten as:
|mailx -s SNI-Mail Elmar(_dot_)Schaetzlein(_at_)muenchen(_dot_)org
You don't need a lockfile if you aren't writing to a file. The 'c'
flag will cause procmail to keep going after it does the action,
which should result in the mail being dump in $DEFAULT
In the end, the rule of thumb is: if you're using global lockfiles
via LOCKFILE, then you're being too smart for your own good.