At 00:38 2002-01-23 -0700, Mark Simpson did scrawl:
the item delivered in the sendmail log and procmail log. The mail is
collected via pop3, which does locking itself too. So there's no possibilty
of mail collection interfering with procmail delivery.
FTR, the "locking" which pop3 does isn't necessarily the same as the
locking which procmail uses on mbox files (dotlocking - basically creating
a semaphore file). POP3 daemons more likely use flock() or a similar function.
Also, the corruption happens in the mailbox itself (i.e. it's not a problem
with POP3), and I didn't get the corruption with any of the procmail rules
I had before this. It's something to do with this specific ruleset.
Something you don't mention is what version of procmail you're using, and
the locking strategy it was compiled with (run 'procmail -v'). Somebody
who knows the details of the different locking strategies might recognize
your woes.
If you think locking issues within the recipe is causing your grief, you
could try producing a global lock of your own around the complete recipe set:
LOCKFILE=/etc/procmailrcs/global.procmail.lock
(all of your stuff, minus the $DEFAULT rule at the end)
LOCKFILE
Doing this will have a detrimental effect if you have a lot of email coming
in because it holds it all up until the running process completes. I used
to do this sort of thing for a rather intensive spam filter process I ran
(because it was a memory hog). Then I got wise and improved the efficiency
of the filter by writing a specialized grep using AVL trees and parsing
custom to my application.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail