procmail
[Top] [All Lists]

Re: Lock Failure

1997-12-18 23:30:52
James Walden <jamesw(_at_)ichips(_dot_)intel(_dot_)com> writes:
On Thu, 18 Dec 1997, Philip Guenther wrote:
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?

I do not own procmail so I don't know how it was originally compiled.  I
suspect it was disabled as all MDAs and MUAs within our organization are
compiled with dotlocking as a standard.  Mail may be read on AIX 3 & 4,
HP-UX 9 and 10, SunOS 4.1.3-4.1.4, Solaris 2.5.1, and FreeBSD 2 & 3 so
I'm rather pessimistic about finding reliable kernel locking mechanisms
among all these OSes. 

I would guess that fcntl() would work, but I've never worked with AIX, so...


What is the uname info for the home directory NFS server?

They are Auspex NFS servers: SunOS pdxfs12 4.1.4 1 aushp

That should be fine.


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.

I just started testing this version (with dotlocking only) with a few
users experiencing this problem but I'll need another week to know how
this goes.  How long have you been using 3.11pre7?

Since the day it came out, 28 April 1997, and we used 3.11pre4 for the
two years preceding that.


Can I use kernel locking in addition to dotlocking so that my locking
technique is still compatible with dotlocking MUAs? 

procmail can _always_ do dotlocking, and the default action (delivery
to $DEFAULT) always uses dotlocking.  Individual recipes can decide to
use dotlocking by putting a second colon on the line that starts the
recipes, with the lockfile name right after that, or (if not there)
implicitly from the action (see the procmailrc(5) manpage for
details).

Philip Guenther


Hmm, if you're feeling inquisitive you could try adding some more
debugging statements to the procmail locking code, say, putting a
perror("procmail") call right after the "faillock:" label in
src/locking.c, to see what the errno involved was.

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