lock_unlock() problem?

[DAVID G MCMURTRIE]

We're running an antique version of cyrus imap (1.5.14), and we've long
been aware of locking problems with the mailboxes file.  It seems that
there are conditions where a process can acquire a lock on the mailboxes
file but never release it, leaving tons of other imapd processes sitting
in a blocking fcntl() call waiting for a lock forever.

I never bothered asking for any kind of support from the list before
because we're running such an old version.  Now this problem seems to be
happening with greater frequency, so we finally started digging through
the code to see if we could determine the cause.

One thing that seems like it could be an issue is in the lock_unlock()
function that still exists in the latest code.  It's in lib/lock_fcntl.c
and lib/lock_flock.c.  I suspect that lock_fcntl.c is being used in our
case since we're running on Solaris.

At any rate, we noticed that the return code from fcntl() is never checked
during the unlock.  It would seem more correct to at least check for EINTR
and retry, since currently any signal delivered to the process during this
system call will cause the unlock to fail, but success will still be
returned to the caller.  FWIW, this condition is checked when the lock is
being established in other routines in the same source file.  Checking for
EBADF would be a nice sanity check that could help point out any logic
errors elsewhere in the code.

Finally, would it make sense for this function to exit(), or return
failure when fcntl() fails?  I don't know the implications of this, but it
seems problematic that the unlock can fail and the application is never
aware of it.

Any insight would be appreciated.

Thanks in advance,

Dave
--
Dave McMurtrie, Systems Programmer
University of Pittsburgh
Computing Services and Systems Development,
Development Services -- UNIX and VMS Services
717P Cathedral of Learning
(412)-624-6413