I thought about a global LOCKFILE, but tried to avoid it since the
documentation discourages it. But that may just do the trick. I'll
also look for "regional" locking.
In a nutshell I'm trying to run a program that uses a lot of processor
(I agree procmail is lightweight), so I want to serialize them, and hence
the attempt at using locallockfiles. But I also want to capture the
output to include in a reply message. When that program exits with
a non-zero status, the output isn't in my variable. Apparently the
combination of a locallockfile and a program that "fails" causes the
assignment to not happen.
Here's a snippet from my real rc file, not my contrived examples. All
referenced variables are set earlier by various means.
-----
:0:/var/tmp/.salearn.$FROM
RESULTS=|su daemon -c "$SALEARN" <$CACHEFILE 2>&1
:0
| (formail -r -I "Subject: your request"; \
echo "Results: $RESULTS") \
| $SENDMAIL -t
-----
I'll try your suggestions.
Ian
-----Original Message-----
From: Dallman Ross [mailto:dman(_at_)nomotek(_dot_)com]
Sent: Saturday, February 21, 2004 11:32 AM
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Subject: Re: varname=| construct broken?
On Sat, Feb 21, 2004 at 11:05:28AM -0700, Ian D. wrote:
Alright, I have a new problem. This is using v3.23pre provided by
Bart. The rc file is as follows:
-----
SHELL=/bin/sh
:0:/tmp/jjj
RESULTS=|/tmp/error
LOG="$RESULTS
"
-----
/tmp/error is a script that returns non-zero:
#! /bin/sh
echo "this is stdout"
/bin/false
-----
Yes, this particular program is useless but demonstrates the issue I
have. I only want one instance to run at once (too many bring my
system to its knees, I have found out.) Hence, the need for locking.
Therefore, I can't just say RESULTS=`/tmp/error`, I want to use a
recipe to leverage locking.
When you run procmail </dev/null, you get no output.
I can remove the lock file from the recipe and this works, but I need
the lock file. The problem also only seems to be when the program
invoked returns non-zero.
These assignment recipes seem really squirrelly to me. I guess I will
have to write to a file and get the output from there. Yuck.
I'm not entirely sure I understand all you wanted to explain. However, it
sounds to me like you might want to be invoking global locking rather than
local. From "man procmailrc":
LOCKFILE Global semaphore file. If this file already
exists, procmail will wait until it has gone
before proceeding, and will create it itself
(cleaning it up when ready, of course). If
more than one lockfile are specified, then the
previous one will be removed before trying to
create the new one. The use of a global lock\xAD
file is discouraged, whenever possible use
locallockfiles (on a per recipe basis)
instead.
It doesn't actually ahve to be global. It can be "regional," as David Tamkin
from this list usefully has named it in the past.
Also, if running a few instances of procmail bogs your system down that
markedly, something else is going on. Procmail is damn lightweight! If you
are running lots of forks and pipes, though . . . .
--
dman (top-posting discouraged on this list)
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail