Hi All, I am trying to work through our file locking problem in Cyrus 2.0.16. Since the problem appears to be tied to locking the seen file, I have recompiled with SEEN_DEBUG turned on to see if I can get any more info. I will let you know anything I find. Any other suggestions on how to gather more info would be appreciated.
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) 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? Second, In the locking architecture used in lib/lock_flock.c, the flock function is called in a blocking fashion with the LOCK_EX operation rather than or'ing this with the LOCK_NB. As a result, if any process gets a lock on a file and fails to release it, all subsequent processes with block permanently. While in a perfect 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. 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 ? Thanks in advance for your help, John Wade
