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