Timothy J Luoma <tjlists(_at_)bigfoot(_dot_)com> writes:
Situation:
I got away for a week, and come back to find over 1000 messages
waiting to be d/l and sorted.
No problem really, except that it takes a long time for them to be
sorted, and so I get this after awhile:
lockfile: Forcing lock on "/usr/spool/mail/tjl.lock"
procmail: Forcing lock on "/usr/spool/mail/tjl.lock"
Which of course causes all sorts of problems as the mail starts to get
sorted again, resulting in a lot of them being caught in my duplicate-check.
Does 'LOCKTIMEOUT=0' tell both lockfile and procmail to NOT force the lock?
Lockfile will only force a lock if you specify the -l option. Setting
LOCKTIMEOUT to zero in procmail will disable its forcing of locks.
However, it appears from the above that you're doing something like:
lockfile $MAIL.lock
formail -s procmail < $MAIL
rm -f $MAIL.lock
That won't work if your .procmailrc ever delivers to $MAIL. When
refiltering a mailbox, move the data to another name and split it from
there, as shown in the scripts at the bottom of the procmail(1)
manpage:
#!/bin/sh
ORGMAIL=/var/mail/$LOGNAME
if cd $HOME &&
test -s $ORGMAIL &&
lockfile -r0 -l1024 .newmail.lock 2>/dev/null
then
trap "rm -f .newmail.lock" 1 2 3 13 15
umask 077
lockfile -l1024 -ml
cat $ORGMAIL >>.newmail &&
cat /dev/null >$ORGMAIL
lockfile -mu
formail -s procmail <.newmail &&
rm -f .newmail
rm -f .newmail.lock
fi
exit 0
Philip Guenther