| Replies again directed to list.
OK ...
When I suggested some code involving lockfile to Aaron Schrab, he replied,
| While most of these users do not have a .procmailrc, there are also
| many that just use it to send spam to /dev/null, but still have
| everything else delivered to $DEFAULT. The number of users that do
| this is likely to increase.
Then my suggestion won't help that case, as we both know. Anyhow, I
proposed this:
| > :0
| > * ! ? test -r $HOME/.procmailrc
| > * ! ? lockfile -r $NUMBER_OF_RETRIES -ml
| > {
| > # Do whatever it takes to requeue a message on your system:
| > EXITCODE=75
| > HOST
| > # Since the lockfile was never created, it needn't be removed.
| > }
And Aaron asked,
| Wouldn't it then lock up when it actually tries to deliver?
Good point; running lockfile doesn't make the lockfile's name known to
procmail the way that setting the LOCKFILE variable does. Let's fix that.
:0
* ! ? test -s $HOME/.procmailrc
{
:0
* ! ? lockfile -r $NUMBER_OF_RETRIES -ml
{
# Do whatever it takes to requeue a message on your system:
EXITCODE=75
HOST
# Since the existing lockfile belongs to a different process, we
# should not remove it.
}
:0Ec # while we have the lock, use it
$ORGMAIL
:0ahi # no w or W!
| lockfile -mu
}
Procmail has dedicated variables like LOCKSLEEP and LOCKTIMEOUT to
simulate lockfile's other options besides -r; if it had one for this
(would NORESRETRY work?) we could do something much saner, like just
setting that variable in /etc/procmailrc (though a cunning user could
change its value in .procmailrc).