The default local mail delivery agent in RH (procmail) uses fcntl locking (as revealed by procmail -v) when delivering mail to user mailboxes in /var/spool/mail. The POP and IMAP daemons use incompatible flock locking on the mail spool files. Since neither locking method respects the other's locks, no locking is actually performed. Random loss of mail messages is the frequent result when both programs access a mail spool file simultaneously. This data loss has been experimentally confirmed. (Both the POP/IMAP servers and procmail also attempt to perform dot file locking on the mail spool files, but strace reveals that the attempts fail due to RH's default directory permissions on the mail spools.) Note that while it is possible to lose messages for the above reason any time a POP/IMAP retrieval attempt occurs at about the same time as the receipt of a message, certain circumstances make loss of data much more likely. In particular, large mail spool files and high system loads increase the likelihood of data loss greatly. This same problem existed in RH 5.0 and 5.1. I reported the problem at that time as well, and it appeared to be fixed in RH 5.2. This problem appears to exists on all RH 6.x releases. The problem is relatively easy to fix. The procmail package is configurable to use several locking styles, including flock, lockf, and fcntl. Currently, a patch in the procmail SRPM disables all styles except dot file locking and fcntl. If this patch is changed so that procmail will compile with flock locking instead (which is what the POP/IMAP servers use) then this problem will go away. Note that other packages that modify the mail spool files, such as pine and elm, should also be examined to make sure they use the same locking style as the POP/IMAP daemons and procmail. Another fix would be to change file permissions on the mail spool directory to make sure that dot file locking can succeed. Default permissions on the mail spool appear to be different in some RH derived releases (including Mandrake), perhaps to address this problem. This might work better for spool directories stored over NFS.
That's the wrong fix. The POP and IMAP servers need to be fixed to use fcntl; flock doesn't work over NFS. Assigning to imap.
Bad news: pine and mail both appear to use flock too and should also be patched. Elm seems to use fcntl. Obviously all of these programs should use the same locking scheme as procmail and the imap and pop daemons. I'm sure there must be a few more programs that access mail spools that I didn't think of . . .
The kernel used to implement flock() over fcntl(), but that changed in 2.2. All mail programs will use fcntl() for locks in the final release.
Hi Has this been fixed in Advisory ID RHSA-2000:102-05 (http://www.redhat.com/support/errata/RHSA-2000-102.html) ? If not, it really should.....