Supress duplicate delivery supression ?

[Per Steinar Iversen]

Is it possible to avoid the use of duplicate delivery suppression?

Today our Cyrus imapd had its delivery database corrupted, after that we
had no new deliveries. Looking at the log it seems that duplicates are
actually detected rather infrequently... I would rather have an occasional
duplicate than a thousand angry users. Is it possibly to not use this 
feature?

Software: Fully updated RedHat 9, cyrus-imapd-2.2.3-2 RPM as distributed
by Simon Matter.

Hardware: Dell 2650 with all files on a RAID5 volume.

The interesting part of the maillog seems to be this:

Feb 18 07:59:10 imap lmtpunix[26720]: DBERROR db4: 6 lockers
Feb 18 08:01:31 imap ctl_cyrusdb[27364]: checkpointing cyrus databases
Feb 18 08:01:31 imap ctl_cyrusdb[27364]: done checkpointing cyrus databases
Feb 18 08:31:31 imap ctl_cyrusdb[30138]: checkpointing cyrus databases
Feb 18 08:31:31 imap ctl_cyrusdb[30138]: DBERROR db4: /var/lib/imap/db/log.0000000128: log file open failed: Permission denied
Feb 18 08:31:31 imap ctl_cyrusdb[30138]: DBERROR db4: PANIC: Permission denied
Feb 18 08:31:31 imap ctl_cyrusdb[30138]: DBERROR: critical database situation
Feb 18 08:31:32 imap cvt_cyrusdb[30141]: DBERROR db4: region error detected; run recovery.
Feb 18 08:31:32 imap cvt_cyrusdb[30141]: DBERROR: dbenv->open '/var/lib/imap/db' failed: DB_RUNRECOVERY: Fatal error, run database recovery
Feb 18 08:31:32 imap cvt_cyrusdb[30141]: DBERROR: init() on berkeley
Feb 18 08:31:34 imap lmtpunix[28803]: DBERROR: error fetching
Feb 18 08:31:34 imap lmtpunix[28803]: DBERROR: error fetching <403314D5.2030406 at oks.hio.no>: DB_RUNRECOVERY: Fatal error, run database recovery
Feb 18 08:31:34 imap lmtpunix[28803]: duplicate_check: error looking up <403314D5.2030406 at oks.hio.no>/user.britabo: cyrusdb error
Feb 18 08:31:34 imap lmtpunix[28803]: DBERROR: mystore: error beginning txn: DB_RUNRECOVERY: Fatal error, run database recovery
Feb 18 08:31:34 imap imap[30146]: DBERROR db4: region error detected; run recovery.

There is a "log file open failed", this is not due to lack of diskplace at least.

Any ideas anyone on how to avoid a repeat performance?

-psi

---
Home Page: http://asg.web.cmu.edu/cyrus
Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html