On January 22, 2002 07:41 pm, you wrote:
At 18:54 2002-01-22 -0700, Mark Simpson did say:
LOGFILE=/var/log/procmail
You didn't elaborate earlier - but is this ruleset in /etc/procmailrcs/ or
is it your personal (within your user dir) .procmailrc ?
It all in one file /etc/procmailrc and gets applied to all incoming messages
for the domain.
It's a virus scanner (or in this case a mailbox reorganisation tool at the
moment :-) ). There are no additional "user" procmail files that are called.
None of the problems are due to permissions, I've checked the procmail
logs and they don't indicate any problems. The lock files do get created to.
During the delivery phase,if number of messages come in together, they
don't get written in order in the mailbox, typically the From line from the
1st message gets scrambled with the 2nd message.
:0 c:$DEFAULT$LOCKEXT
/var/mail/backup
When I said to lock it, I meant to just "lock" it:
:0c:
I tried a variety of things, including locking without specifying the lock
file. In the end, I thought it would be safer just to see if "one big lock",
that was determined by the destination on a per mailbox basis. None of them
worked.
/var/mail/backup
Ask yourself "should I really be writing my "backup" file to /var/mail
rather than my own dir?" and "do I have rights to do this?"
The permissions are okay. /var/mail/backup is a directory, and the messages
are getting stored in there one per file. The 2 "backup" rules were taken
from "man 5 procmailex" (part of the procmail distribution), and are in
there to protect against mistakes during "rule" development (they recommend
it in the manual page).
ANYWHERE this file is written to must be locked with the SAME lockfile -
$DEFAULT$LOCKEXT isn't the way to do it - that'd be a lockfile for your
default mailbox name, not for this file (not that it _couldn't_ work, but
it is just totally wrong to do it that way).
Thanks for the advice. It was just a last ditch attempt to make sure
everything was locking on the same file.
But wait - I didn't carefully note that your following rule was for dealing
with a MAILDIR format (most folks are using mbox). In this case, remove
the locking - that's only used for mbox (files which contain multiple
messages).
:0 ic:$DEFAULT$LOCKEXT
:
| cd /var/mail/backup && rm -f dummy `ls -t msg.* | sed -e 1,100d`
|
:0
Will do. It's only the backup stuff in MAILDIR format, all other mailboxes
are in mbox format.
:0:$DEFAULT$LOCKEXT
$DEFAULT
$DEFAULT is just that - default. No need to explicitly create a rule for
it. Get rid of this one.
I was clutching at straws on this one. At one point I was convinced that
as everything else was locked, it must be the final delivery at the end, so
I put the last rule in to make sure it was being locked (even though it
should be anyhow). I'm that desperate :-)
EXACTLY which mail file is getting hosed? Since it appears you're doing
this from /etc/procmailrcs/ is there any chance that the mailbox that is
being corrupted is say, the USER mailbox, and if so, is that user running
See details above about the corruption.
I've ruled out any corruption due to other things. I.E. Sendmail delivers
via procmail with no exceptions and every message will go through the
same filter. I'm the user, and I hit the "check mail" button after I've seen
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.
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.
I'm really stumped. I've tried the standard ways in the examples, and I've
tried your suggestions so far (all of which make sense), but it still
happens.
Thanks
Regards
Mark Simpson
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail