On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote:
On Thu, Dec 23, 2010 at 3:03 AM, Anne Wilson cannewilson@googlemail.com
wrote:
All the recipes work perfectly - it's just those that fall off the end. For some reason it overrides the DEFAULT setting in procmailrc.
I'm seeing messages from you about this on the procmail list as well so pardon me if I've got my threads confused, but did you indicate this has been happening some of the time for several days before you noticed it?
From the dates of messages I found in /var/mail/anne, it began on the day I left for a short vacation. Consequently it was 5 or 6 days before I noticed. Few message fail the procmail recipes, normally, so I don't expect to see many there.
Have you determined that it's consistent for any message that "falls off the end" or is it intermittent?
I found that yesterday morning at 6 am messages were being delivered correctly, including a couple that "fell off the end". Suddenly though, things changed. In the logs I saw messages about by-passing a lock file. I'm wondering if some of the longer html messages are causing locks to be set that don't expire in time for the next message. I do remember in the past using the setting for No Lock (and yes, I read the warning), but can't remember where I found that. I'll think more about that.
If its consistent and there's a reasonably well-defined time that it started happening, you should be looking for changes to the system such as an automatically-applied update that occurred shortly before the symptoms began. However ...
Earlier in this thread you said MAILDIR=/home/anne/Maildir/ ... but MAILDIR is procmail's equivalent of the shell's PWD, it has nothing to do with delivery except as the path prefix if you use a relative path name in a delivering recipe. Assigning to MAILDIR is just a "cd".
Have you tried DEFAULT=/home/anne/Maildir/ ?
No, I haven't touch the settings, because they have worked well for several years.
This is a recent development, and in the log I see LASTFOLDER - is it possible that DEFAULT is no longer read and I need to define LASTFOLDER?
LASTFOLDER is informational, procmail sets it immediately before delivering to that folder; if you see LASTFOLDER in your logs, the only way the message should fail to arrive in that folder is in the event of an error writing to that folder.
They do arrive there - it just defines it as /var/mail/anne, which is useless on my IMAP server.
I don't recall whether setting DEFAULT to a pipe (e.g., to delivermail) is supposed to work, but I wouldn't rely upon it. In some simple tests I tried, the pipe was never opened and the mail was passed through to standard output. Setting DEFAULT to a file or directory worked.
In fact I misquoted when I first wrote. The line I gave is correct, but it should have been followed by DEFAULT=$MAILDIR/new/
In fact my logs show no mail going to /var/mail/anne today, so I will have to watch and wait. I repeat, I'm using a procmailrc that has worked perfectly for years.
If you haven't already, you really should add
LOGABSTRACT=all VERBOSE=yes
When I first set this up it was with a printed set of documentation. I do have VERBOSE=YES, but I have LOGABSTRACT=YES. Are these equivalents or has something changed in the meantime? Not that I'm worried about that - I repeat, everything has been fine up to now.
to your procmailrc until you have resolved the problem. This isn't a guarantee that you'll be able to track it down but it'll help eliminate a lot of possibilities.
I've not had a single message to my Inbox today, but nor have any ended in the Local mail account, so I'll just have to wait to see whether the problem recurs.
Anne