procmail
[Top] [All Lists]

Re: lockfile on INCLUDERC to throttle?

1999-12-11 14:36:09
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

<Prev in Thread] Current Thread [Next in Thread>