Red Hat Bugzilla – Bug 117034
strange error message Couldn't create "/var/spool/mail/pat"
Last modified: 2007-11-30 17:10:37 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 Description of problem: I have a simple mail setup with fetchmail and procmail. procmail says that it cannot create a /var/spool/mail/pat (pat is the user login), but it seems to me that it shouldn't try to make anything in that file. Maybe it tries to make a lockfile in that directory ? It is possible that the directories or files don't have the right permissions. (Mail is drwx------) Here is my files: .fetchmailrc -rw-------: poll imap.free.fr with proto imap user 'pertusus' there with password '.....' is pat here mda "/usr/bin/procmail -Y -d %T" .procmailrc -rw-rw-r--: PATH=/bin:/usr/bin MAILDIR=$HOME/Mail DEFAULT=$MAILDIR/inbox #LOGFILE=$MAILDIR/.procmail-log VERBOSE=off PMDIR=$HOME/.procmail LOGFILE=$PMDIR/log #INCLUDERC=$PMDIR/general.rc # INCLUDERC=$PMDIR/other.rc # add as many INCLUDERC's as you like # end of .procmailrc :0: * ^TO_fedora-devel-list fedora-devel-list :0: * ^TO_fedora-test-list fedora-test-list Here is the problem: I call fetchmail [pat@localhost pat]$ fetchmail -d0 fetchmail: 4 messages (3 seen) for pertusus at imap.free.fr. fetchmail: skipping message pertusus@imap.free.fr:1 not flushed fetchmail: skipping message pertusus@imap.free.fr:2 not flushed fetchmail: skipping message pertusus@imap.free.fr:3 not flushed fetchmail: reading message pertusus@imap.free.fr:4 of 4 (2817 header octets) ..fetchmail: (421 body octets) .procmail: Couldn't create "/var/spool/mail/pat" fetchmail: flushed See the error message 'procmail: Couldn't create "/var/spool/mail/pat"' The mail is delivered to the right directory. Here is what is appended to my .procmail/log (showing everything is right). From pat Fri Feb 27 17:35:42 2004 Subject: Where does Download Manager save files? Folder: fedora-test-list Version-Release number of selected component (if applicable): procmail-3.22-11 How reproducible: Always Steps to Reproduce: 1. get mail with fetchmail redirecting to procmail and no /var/spool/mail/user 2. 3. Actual Results: everything was right, except that procmail said procmail: Couldn't create "/var/spool/mail/pat" Expected Results: no such error message Additional info:
/var/spool/mail should have permission drwxrwxr-x.
[pat@localhost pat]$ ls -ld /var/spool/mail/ drwxrwxr-x 2 root mail 4096 fév 16 23:59 /var/spool/mail/
Is this still a problem?
Yes. I have updated with yum, now I have procmail-3.22-14 fetchmail-6.2.5-5 and still the same problem.
This issue occurs because procmail can't create default mailbox at /var/spool/mail/pat. FC use procmail without S_ISUID, so you need create default mailbox (/var/spool/mail/pat) or set rights of /var/spool/mail/ to drwxrwxrwx or set S_ISUID for /usr/bin/procmail.
I think this is really a bug, as there is no reason why procmail should try to create the default mailbox /var/spool/mail/pat with a setup like mine. Or maybe there is a reason? In my setup I explicitely define my maildir to be something else than /var/spool/mail/pat: MAILDIR=$HOME/Mail DEFAULT=$MAILDIR/inbox
Ok, I'll check it.
/var/mail/$LOGNAME is $ORGMAIL environment variable used by procmail (path to system mailbox). It can be overridden, you have to set $ORGMAIL and use -p and -m command line arguments for procmail.
I tried to set ORGMAIL to nothing in my .procmailrc, but it doesn't prevent procmail from trying to create /var/mail/dumas. It doesn't change if I set it in the environment. I cannot use -p, as I allready have -d on the command line. Indeed I call procmail from fetchmail: mda "/usr/bin/procmail -Y -d %T" procmail dies with an error if I try to set -p with -d. Anyway it is documented, from the man page: /var/spool/mail/$LOGNAME system mailbox; both the system mailbox and the immediate directory it is in will be created every time procmail starts and either one is not present Maybe this is a procmail "feature". I think that it should be possible to prevent procmail from trying to mess with the system mail directory when in pure user delivery mode more easily, but it is not a real problem. Anyway I think it should not be closed as NOTABUG but WONTFIX or UPSTREAM. Not a big deal.