In a previous episode, David W. Tamkin said, and I quote:
You could assign LOCKFILE at the beginning of the INCLUDERC file and unset it
at the end of the INCLUDERC file instead of doing those things in your
.procmailrc. That would be one way. It is then possible that several
concurrent procmails might have the INCLUDERC file open for reading, but only
one could be actually processing its recipes at any given time.
Could you explain why that would be any different than wrapping the recipe
with the explicit LOCKFILE directive as I was doing? Seems to me that once
the LOCKFILE is encountered, the processing should hold there until the
lock clears - as long as it encompases the critical section, what would the
difference be?
| As a recent 64 message fetchmail process confirmed, this didn't work as
| expected.
without describing the unexpected thing that happened instead.
It merrily executed concurrent processes on the separate messages. i.e.
didn't work as I'd expected the explicit LOCKFILE to work.
Given that something went awry, my first thought is, what is the value of
$TEMP? Is it a publicly writable, albeit sticky, directory? Maybe procmail
TEMP=/tmp
World writeable.
doesn't like having lockfiles in directories writable by more people than
just the procmail process owner and root? (If that's true, I don't see why;
sure, someone else can have a lockfile there and delay your mail, but soon
Well, it would be good to know what the answer to this one is, since that
could play a role.
Chaning the TEMP variable to point to a user-local tmp directory, with 755
permissions changes nothing.
enough the other person's lockfile will be removed or will be deemed stale.)
Does a verbose logfile say that the lockfile couldn't be acquired?
Verbose isn't normally on (whoa, no way am I doing that with the volume of
spam filtering that goes on, combined with the volume of mail I
receive). Seeing as this process thoroughly thrashes the system, I'm not
particularly enamoured of repeating it: I'd just as soon make the changes
that SHOULD fix the problem, then run a controlled test to confirm that it
is fixed.
Your suggestion of:
LOCKFILE=$TEMP/spamsrc$LOCKEXT # or maybe under $HOME somewhere
INCLUDERC=$PMDIR/spam/spam.rc
LOCKFILE
works as desired.
I was wrapping outside the rule itself on the basis that it didn't do much
good to have a score of messages all running the immediatley preceeding
greenlist check if they couldn't proceed to do the spam portion (although,
your way means that those messages which pass can continue to be processed,
even if another message is being thoroughly spamchecked at the time). Very
few items are listed in the greenlists though.
| Placing a lockfile on the recipe itself (:$TEMP/spamsrc$LOCKEXT on the
| flags line) doesn't seem to accomplish anything at all ...
True. Local lockfiles requested with a second colon are meaningless when the
action is an opening left brace. [That is, unless the `c' flag is present to
Well, that answers a lot: I'd always taken the approach of specifying a
local lockfile explicitly because the ones that were auto generated were so
damn goofy (using something of a filename based on the final delivery line
- even if to a program, rather than the actual part which needed locking).
If I have a sequence of events, and I want to lockfile the sequence, how
would I accomplish that? Say, matching on a header, then filtering it,
creating an interrim file, and then doing something with that. Seems you
couldn't rely on bracing, but instead would have to make use of a mess of
sequential recipes using the 'A' flag.
The prospect of a perl implementation of procmail becomes more and more
appealing...
Thank you for the assist.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395