Timothy J Luoma <luomat(_at_)peak(_dot_)org> writes:
Did you give enough directories to the locking tests?
All the mail goes on the same system, on one disk. How many
directories should I give it? It would seem that this setup would
not require more than one directory for locking tests, and if my
setup is not the perfect setup for one directory, then what system
is procmail's default (just using /tmp) designed for?
Since no NFS is involved here, that's just fine.
Do all the recipes in your .procmailrc that write to your mailspool
the the _correct_ locallockfile?
This I do not understand. I have only two recipes which actually
dump to $DEFAULT (the rest just fall off the end of the procmailrc),
and both are used this way:
This is about halfway through my .procmailrc:
:0:
* ^Subject: (NeXT_FTP_Report|\
NEXTSTEP/OpenStep Resources on the Net)
$DEFAULT
...
You have the second colon on each one (":0:") so the default locallockfile
is being used. This is correct.
Is this correct? Here is my procmail -v info:
procmail v3.11pre4 1995/10/29 written and created by Stephen R. van
den Berg <srb(_at_)cuci(_dot_)nl>
3.11pre4 is good.
With your mailreader, are you *sure* it has a locking strategy
in common with procmail?
My main reader only accesses the spool when I tell it to (manually)
and none of this has ever happened when I was telling it to
retrieve mail from the mailspool. I can see when my POP binary
starts to run, which passes the mail to procmail, and I can see when
it exits (ie procmail is far done by the time I tell my mailreader
to go for my mailspool). Therefore I do not think that this has
anything to do with my mail reader.
Actually, if it is an interaction with your mailreader, it is mostly
likely to happen when you _finish_ reading mail and your mail reader
is rewriting the mailspool to reflect what you deleted from it. What
mail program do you use? How old/what version is it?
You may have nailed the problem. This is very sporadic, so I can
only guess that the problem is intermittent, but for the life of me
I can't find any common thread that might be the problem.
The final possibility is that some other program is writing to your spool.
You don't have some wonky version of the old /bin/mail lying around that
a shell script out of the past could be calling directly?
Philip Guenther