procmail
[Top] [All Lists]

Re: Lock Failure

1997-12-18 15:32:32
James Walden <jamesw(_at_)ichips(_dot_)intel(_dot_)com> writes:
I am using procmail 3.10 on Solaris 2.5.1 as a delivery agent for sendmail
8.8.8.  Several times a week, a few users who receive simultaneous mails
end up with concatenated mails and a 'lock failure' error in their
procmail logs.  Is there a fix for this problem?

I have been unable to repeat the problem under controlled conditions
despite delivering several messages a second for extended periods of time
using the user's .procmailrc file.  I am using dotlocking with an NFS
mounted mail spool (with mode 1777).  The problem in these abstracts
occurs when delivering to an NFS mounted user home directory.  Logfile and
procmailrc extracts along with version information on the mail server and
procmail are included below.
...
procmail: Locking "/fs12/q/username/Mail/mbox.lock"
procmail: Locking "/fs12/q/username/Mail/mbox.lock"
procmail: Opening "/fs12/q/username/Mail/mbox"
procmail: Lock failure on "/fs12/q/username/Mail/mbox.lock"
procmail: Opening "/fs12/q/username/Mail/mbox"
...
------------------------ machine and procmail info -------------------------
# uname -a
SunOS ichips-ra 5.5.1 Generic_103640-12 sun4u sparc SUNW,Ultra-Enterprise

# procmail -v
procmail v3.10 1994/10/31 written and created by Stephen R. van den Berg
...
Locking strategies:     dotlocking
Default rcfile:         $HOME/.procmailrc
System mailbox:         /usr/spool/mail/$LOGNAME


Is there some reason your procmail was compiled without kernel
locking?  Did the autoconf process actually decide that none were
usable, or were they explicitly disabled?  What is the uname info for
the home directory NFS server?

Offhand, my first suggestion would be to upgrade to 3.11pre7 (yes, it's
stable), watching the autoconf process carefully to make sure it gets a
real chance to test kernel locking.

Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>