On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote: > On Thu, Dec 23, 2010 at 3:03 AM, Anne Wilson <cannewilson at 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 -- KDE Community Working Group New to KDE Software? - get help from http://userbase.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.centos.org/pipermail/centos/attachments/20101223/9e93f99f/attachment-0005.sig>