Hi, On Thu, 17 Oct 2002 09:10:44 -0400 (EDT), Rob Siemborski <[EMAIL PROTECTED]> wrote... > On Thu, 17 Oct 2002, Mark Keasling wrote: > > > I'm trying to use Berkeley DB 4.0.14 and am getting the dreaded > > DBERROR db4: 4 lockers > > messages even when only starting up the master process. From > > what I've seen reported, the lockers number will only increase and > > cyrus will eventually start failing. > > DB4.0 has a known (cosmetic) bug that causes this number to monotonicly > increase (they apparently are missing a decrement). So as long as it is > only increasing at a slow rate and you aren't seeing any other problems, > all is well with the world. > > I don't believe any recent version of cyrus has a major Berkeley DB > locking problem. Of course, we also recommend using the skiplist backend > for the mailboxes.db file.
Rob, thank you for this information. My database configuration is currently: --with-duplicate-db=db3_nosync --with-mailbox-db=db3 --with-seen-db=flat --with-subs-db=flat --with-tls-db=db3_nosync I'll change the configuration for mailboxes.db from the default db3 to the recommended skiplist. There is a need to know the extent to which the lockers bug will require administrative involvement. I'm planning to install cyrus but won't be the entity administrating it. I need to know in advance what problems (may | will) be encountered and what has to be done to correct them. Ideally after installation the only administration required would be user additions and deletions. Please bear with the innumberable dumb questions... The duplicate and tls databases are configured as db3_nosync. Will these also exhibit the lockers problem? (The error message doesn't indicate which database is having the lockers problem.) What problems occur with the lockers values reaches the max value? Is it possible to use a different type of database? (ie, gdbm,ndbm) Since they aren't used, most probably they can't be. Has anyone tried to figure out what circumstance(s) causes the lockers value to not be decremented? or what may be done to inhibit interminal incrementation? (ie a s{i,a}mple program that exhibits the lockers problem) Has anyone looked at the database code in an attempt to determine were the bug is? (Does anyone have that much free time?) Are there any actions that "reset" the lockers value? Or is it permanent. Once the value reaches the max, you have to throw away the database and start over? Is is possible to dump and rebuild the database(s)? Can the database recovery be automated? At what frequency would the lockers value reach the maximum (under ordinary conditions (someone reported weekly)) and administrative action be required? Once every ten years isn't really much to worry about; but once a week is ridiculus. I'd say that more than once a year may be considered excessive. Is there a way to determine what the lockers value is so that an estimated time to failure can calculated? If the failure time can be determined in advance, maintenance can be scheduled before hand rather than having an "emergency" were the system unexpectedly fails and must be fixed immediately. Regards, Mark Keasling <[EMAIL PROTECTED]>