duplicate delivery suppression is unreliable

Henrique de Moraes Holschuh hmh at debian.org
Tue Feb 1 15:32:31 EST 2005


On Tue, 01 Feb 2005, Kyle Silfer wrote:
> Andreas Hasenack <andreas at conectiva.com.br> said:
> > > > Exactly what DB4 version? I'm using 4.2.52 + two patches and never had this
> > > issue.
> > > 
> > > This is 4.1.25 from the SuSE 9.0 install CDs.
> > > 
> > > Are you saying this version may be buggy and I should have the latest?
> > 
> > You should check to see if your package has the two official patches from
> > sleepycat:
> > 
> > http://www.sleepycat.com/webforms/patchdl.php?src=patch.4.1.25.1
> > http://www.sleepycat.com/webforms/patchdl.php?src=patch.4.1.25.2
> 
> Turns out it had patch 1, but not patch 2. I recompiled from the source RPM
> and upgraded my installation. Same issues: duplicate suppression is
> unreliable. Should I have done some db_recover or db_checkpoint stuff?
> 
> > Other than that, you may need to tune your DB_CONFIG file to get rid of
> those locking
> > problems, but check the patches first.
> 
> OK, I have no DB_CONFIG file nor configuration files of any kind, near as I
> can tell. The RPM only installed a bunch of library files and the db_ series
> of utilities. 

Do a search on this ML archives.  I have sent some stuff about DB_CONFIG
sometime ago.  Basically, whatever you do with it, do it with cyrus stopped.
Also, don't let libdb4.x run out of memory space (but THAT is not anywhere
near common a problem with Cyrus imap, thanks $deity.  Now, slapd on the
other hand...).  You will need to run db_recover for any DB_CONFIG changes
to actually take effect.

BTW, at least in Debian, db 4.2 had to take some very insiduous patching to
the mutex code (backported to db 3.x too this week :P) to avoid nasty
hangups on ia64, amd64 (db 3.x, db 4.x), and also database corruption on
i386 SMP and SMT (only db 4.x with slapd).  These patches probably made it
upstream (and for all I know, they might have originated in Fedora).

So, you better know very well what you are doing when dealing with Berkeley
DB.  OTOH, there is nothing as fast for the mailboxes DB as a well tuned
db4.2/db4.3 (for Cyrus IMAP, anyway).

One extra note: Cyrus attempts to setup some saner defaults for Berkeley DB,
but *these will work only when Cyrus gets to generate the DB environment
from scratch*.  IMHO you are much better off with a DB_CONFIG; at least
db_recover will reapply the settings to the environment anytime you need it
to.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html




More information about the Info-cyrus mailing list