procmail
[Top] [All Lists]

Re: lockfile on INCLUDERC to throttle?

1999-12-10 23:05:18
Sean Straw wants a regional lockfile around an INCLUDERC call because the
code in that INCLUDERC file should be run in only one invocation at a time.

| The old scheme had:
| 
|       LOCKFILE=${HOME}/.procmail.global-procmail.lock
| 
| at the top of .procmailrc
| 
| and:
| 
|       LOCKFILE
| 
| at the end.

| I'd still like to know how to properly wrap an INCLUDERC in a lockfile.

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.

| The revised scheme was to comment out the above two lines, and do the
| following instead:

| LOCKFILE=$TEMP/spamsrc$LOCKEXT
| 
| :0
| * ! $? $FORMAIL -ISubject: | $FGREP -i -f $NOSPAMLIST
| {
|          INCLUDERC=$PMDIR/spam/spam.rc
| }
| 
| LOCKFILE

Now, one thing I couldn't understand from your post, Sean, was exactly what
goes wrong and why that doesn't work.  All you said was this:

| As a recent 64 message fetchmail process confirmed, this didn't work as
| expected.

without describing the unexpected thing that happened instead.

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
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
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?

Since the fgrep on the condition line isn't the resource hog and it doesn't
modify any files, this can help and certainly can't hurt:

  # `$' modifier is redundant on exit code conditions, especially with 
  # a character from $SHELLMETAS present
  :0
  * ! ? $FORMAIL -ISubject: | $FGREP -i -f $NOSPAMLIST
  {
   LOCKFILE=$TEMP/spamsrc$LOCKEXT # or maybe under $HOME somewhere
   INCLUDERC=$PMDIR/spam/spam.rc
   LOCKFILE
  }

That saves the effort of getting the lock for greenlisted mail.  Also, only
one procmail invocation at a time could be even reading the INCLUDERC.

| 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
launch a clone and the `w' or `W' flag is present to get the parent procmail
to wait for an exit code (and thus for an exit signal) from the clone; then
procmail will wait to get the lock before cloning and will release the lock
after the clone exits, in effect creating a global lockfile for the clone. 
(It might work just `c' without `w' or `W'; I'm not sure.)]

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