patch: improving error reporting in mailfold.c

This is a multi-part message in MIME format.
--------------010105040106060607020005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

I recently ran into a problem which took a while to track down, and in 
the process I wound up hacking a little patch into procmail.  I thought 
I would share it here, in the hopes that someone may clean it up and 
possibly include it in future versions.

Initially, I was getting bounced mail with errors of the form:

Diagnostic-Code: x-unix; procmail: Couldn't create "/var/mail/foo"

however, in this case the user's mailbox should have been 
/home/foo/mailbox, so the error struck me as being odd.

looking in the postfix log didn't reveal anything more helpful:

status=bounced (can\'t create user output file. Command output: 
procmail: Couldn\'t create \"/var/mail/bass\" )

checking the user's procmail log revealed more useful information after 
enabling the VERBOSE=on option in the user's ~/.procmailrc:

procmail: Error while writing to "/ices/foo/mailbox"
procmail: Truncated file to former size

So, it appears procmail couldn't write to the user's mailbox, and fell 
back to the default of /var/mail/foo, which didn't exist, and finally 
bounced.  But why couldn't it write to the mailbox?  I had checked file 
permissions and even written a python script to check for fcntl and 
flock file locks, but everything looked correct.

Finally, I started grepping the source code of procmail and traced the 
error down to a few possible locations, which lead me to this chunk of code:

dumpf:   { switch(errno)
         { case ENOSPC:nlog("No space left to finish writing"),logqnl(buf);
          break;
#ifdef EDQUOT
           case EDQUOT:nlog("Quota exceeded while writing"),logqnl(buf);
          break;
#endif
           default:writeerr(buf);
         }

well, it turns out my error was in the "default" case, which is why I 
was getting the rather generic error of "couldn't write to file".  I 
then patched it to print out the corresponding errno message, which 
resulted in output like so:

procmail: mailfold.c:241: errno: 27
procmail: File too large

This of course was remedied by adjusting mailbox_size_limit in postfix's 
main.cf.

Anyway, I am including my (somewhat hackish) patch in the hopes that in 
the future this type of error won't be quite so difficult to track down.

Thanks,
Jason Pepas

--------------010105040106060607020005
Content-Type: text/x-patch;
 name="sysnetdebug.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sysnetdebug.patch"

diff -urN procmail-3.22/src/mailfold.c procmail-3.22-patched/src/mailfold.c
--- procmail-3.22/src/mailfold.c	2001-09-10 23:58:34.000000000 -0500
+++ procmail-3.22-patched/src/mailfold.c	2007-04-13 14:18:34.000000000 -0500
@@ -235,7 +235,16 @@
 	      case EDQUOT:nlog("Quota exceeded while writing"),logqnl(buf);
 		 break;
 #endif
-	      default:writeerr(buf);
+	      default:
+                 writeerr(buf);
+                 {
+                     #define MSGBUFLEN 1024
+                     char msgbuf[MSGBUFLEN];
+                     snprintf(msgbuf, MSGBUFLEN, "mailfold.c:241: errno: %i\n", errno);
+                     nlog(msgbuf);
+                     nlog(strerror(errno));
+                     nlog("\n");
+                 }
 	    }
 	   if(lasttell>=0&&!truncate(boxname,lasttell)&&(logopened||verbose))
 	      nlog("Truncated file to former size\n");	    /* undo garbage */

--------------010105040106060607020005--