Date: Fri, 02 Nov 2001 09:07:32 -0600 From: John Wade <[EMAIL PROTECTED]>
I did have a couple of questions that came out from looking at the source. First, in seen_db.c although all the comments reference the Berkely DB structure for the seen file, there is a define statement /* choose "flat" or "db3" here */ #define DB (&cyrusdb_flat) The "cyrusdb" structure is a layer of abstraction allowing either flat text files or db3 files. This seems to mean that Cyrus uses the old style text file to store the seen info rather than a Berkely DB. Is there a particular reason this is defined this way by default? Is the Berkeley DB style seen format safe to use and/or preferred? The problem is that a large number of small btree files is inefficient. If you are interested in using Berkeley db for seen state (probably more efficient in the long run) look into "seen_bigdb.c". However, it's unlikely that the locking problem you're experiencing will go away by using Berkeley db---in fact, it will probably be worse since you won't be able to kill just one process---you'll have to kill everything and run recovery. [...] world, this would be fine, since locks appear to be released when processes terminate, in my world, this seems to cause a cascade failure where once a mailbox gets locked, eventually mail delivery dies when all of my deliver processes are hung up waiting for the user's mailbox to be unlocked. Is there any reason not to try to call flock in a non-blocking fashion with some limited number of retries ( perhaps delayed with additional attempts tried at increasing intervals) until finally after 5 minutes or so we fail with an error. I was going to give this a try unless somebody already knows why this is a bad idea. This obviously can work, but it doesn't really help us find the root cause of the problem. Third, I suspect (after looking at the open files in use by the imap process after terminating an IMAP connection) that the problem may be exacerbated by, or related to process reuse, can anyone point me to how to disable this feature for imapd ? It's really crucial to understand what process is holding this lock. It might not be reused---it's probably blocked doing something else and never releasing the lock. imapds should never do something that will block for a long time while holding a lock but evidentally something is wrong. Finding the process that holds the lock, doing a backtrace on it and (even better) figuring out how it gets into that state is really the crucial issue for fixing this problem. Larry
