#!/bin/sh
LOCKFILE=${HOME}/.procmail/global-procmail.lock
while [ -r $LOCKFILE ]; do
sleep 5
done
touch $LOCKFILE
/usr/local/bin/compactmail -u -d 3 Backups
/bin/rm -f $LOCKFILE
exit 0
But what happens if mail comes in right between the 'done' and the
'touch' lines? I realize it's a longshot....
You've missed a crucial portion of the procmail documentation. Read the
man page on the 'lockfile' command -- it's a command line interface to
the same locking mechanisms that procmail uses. You script would end up
looking something like:
#!/bin/sh
LOCKFILE=${HOME}/.procmail/global-procmail.lock
if lockfile $LOCKFILE; then
/usr/local/bin/compactmail -u -d 3 Backups
/bin/rm -f $LOCKFILE
fi
The lockfile command will retry the lockfile indefinately. You can
change this behavior (i.e., have it give up after n retires), as well as
the sleeptime between lock attempts, the timeout on lockfiles, and more
via command line parameters.
One caveat: in the procmail world, locks are only valid for a certain
length of time -- this is to prevent problems caused by lockfiles left
by errant processes. If a lockfile is older than this value, it loses
its locking power. The 'lockfile' command lets you set this value via a
command line switch; procmail uses the LOCKTIMEOUT variable. From the
procmailrc man page:
LOCKTIMEOUT Number of seconds that have to have passed since
a lockfile was last modified/created before
procmail decides that this must be an
erroneously leftover lockfile that can be
removed by force now. If zero, then no timeout
will be used and procmail will wait forever
until the lockfile is removed; if not specified,
it defaults to 1024 seconds. This variable is
useful to prevent indefinite hangups of
sendmail/procmail. Procmail is immune to clock
skew across machines.
If compactmail takes a while to run, you may need to play with the
LOCKTIMEOUT value.
-- Lars
--
Lars Kellogg-Stedman * lars(_at_)bu(_dot_)edu * (617)353-8277
Office of Information Technology, Boston University