On Thursday 22 April 2004 13:22, Rick Stevens wrote: > Tim Alberts wrote: > > On Thursday 22 April 2004 12:54, Alexander Dalloz wrote: > >>Am Do, den 22.04.2004 schrieb Tim Alberts um 21:48: > >>>I changed no permissions from the default. The permissions are as > >>>follows: > >>> > >>>ls -ld /var/ /var/spool/ /var/spool/mail/ /var/spool/mail/talberts > >>>drwxr-xr-x 30 root root 4096 Apr 15 14:19 /var/ > >>>drwxr-xr-x 25 root root 4096 Feb 12 16:11 /var/spool/ > >>>drwxrwxr-x 2 root mail 4096 Apr 22 11:47 /var/spool/mail/ > >>>-rw-rw---- 1 talberts mail 556 Apr 22 11:50 > >>>/var/spool/mail/talberts > >> > >>So which client do you use? Please be more descriptive what exactly you > >>do. I only saw the maillog error message complaining about wrong mailbox > >>permissions on bugzilla when someone did use mutt with wrong setup. > >> > >>Alexander > > > > I got this to happen on two Fedora Core 1 systems. My network mail > > server which is a heterogeneous with Windows Mac and Linux workstations. > > Also on my personal workstation after I discovered the problem I tested > > it on my own system. Full install of Fedora core 1 with nothing special > > I can think of to mention. > > > > I need to explain further that the error message is in > > /var/spool/mail/user file, but when I use pop3 (via kmail on localhost, > > or over the network) to get the email I don't get the message downloaded, > > I don't get any errors from the client side. I also don't get any emails > > delivered either. I have to log into the server and access the > > /var/spool/mail/user file direction to see the error message. > > > > After the error occurs, I can delete /var/spool/mail/user and the thing > > will work again for a short period of time (sometimes it fais > > immediately). > > Uhm, hmmm. That smells of several possible issues. One would be > multiple simultaneous POP sessions on a single mailbox and the pop > server isn't arbitrating them correctly. That's caused by the pop > server ignoring the lock files or flock() results. > > Another would be multiple POP servers talking to the same mailbox. > /var/spool/user isn't on an NFS mount, is it? You don't have multiple > POP servers talking to it, do you? Without modifying code, multiple POP > servers won't work right with NFS-mounted mailboxes. POP servers, by > default, depend on the file locking mechanisms in the kernel to > arbitrate access. These locks are not shared by multiple servers, so > system B won't know if system A already has the mailbox open > . > The code must be changed to check for the existence of the lock file. > If it's there, either another POP session is in operation or a delivery > into the mailbox is being attempted. In either case the POP server > should abort the session. > > Yet another is that you're popping the mailbox when procmail tries to > deliver into it. Again, this is procmail and the pop server not using > the same lock files to determine if the mailbox is in use. > ---------------------------------------------------------------------- > - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - > - VitalStream, Inc. http://www.vitalstream.com - > - - > - Never put off 'til tommorrow what you can forget altogether! - > ---------------------------------------------------------------------- First, I humbly thank you for your feedback. I have disabled the main server and I'm just testing this on my local workstation. There are no NFS or fileshares of any kind going on either system. I could imagine the possibility that procmail and pop3 are trying to access the mail file at the same time on the server, but on my single workstation with no file shares, no access to pop3 except localhost and only one email client running (kmail) at a time, I don't think this is the source of the problem. I am curious if two programs (procmail and ipop3d or other) try to access the same email file that is locked, what program is writing the error message into the mail file? My understanding of two programs accessing the same file at the same time is a bunch of garbage and bad things happen. Not a clean consistently formated error message being written into the mail file.
