Rob Mueller wrote:
I don't know anyone who uses BDB for critical DB's in cyrus. They're too
big for seen/sub state db's, too slow for enumerating across the
mailboxes db, which really only leaves suplicate delivery and tls cache
dbs.
HP-UX people. The mmap() implementation on HP-UX won't do
:21 AM
Subject: Re: reoccuring DBERRORs
On Sat, 25 Feb 2006 09:59:31 +1100
Rob Mueller [EMAIL PROTECTED] wrote:
We have seen many strange problems with BDB over the years. It's taken
quite
a bit of fiddling of /var/imap/db/DB_CONFIG values to get a BDB
environment
that will run stably over
Simon Matter wrote:
I guess your cyrus configdirectory is /var/lib/cyrus. Then, did you try
removing the transaction logs in /var/lib/cyrus/db after removing
deliver.db and tls_cache.db?
No, I didn't. I've thought about it, but none of the messages I've read
in the archives mentioned
When I shut down Cyrus cleanly, which of the files in /var/lib/cyrus/db
can be deleted safely along with deliver.db then?
FYI, we're using 2.3 and have:
duplicate_db: berkeley-nosync
seenstate_db: skiplist
subscription_db: flat
mboxlist_db: skiplist
And our cyrus start script does:
On Fri, 2006-02-24 at 21:39 +1100, Rob Mueller wrote:
When I shut down Cyrus cleanly, which of the files in /var/lib/cyrus/db
can be deleted safely along with deliver.db then?
FYI, we're using 2.3 and have:
duplicate_db: berkeley-nosync
seenstate_db: skiplist
subscription_db: flat
On Fri, 24 Feb 2006, Kjetil Torgrim Homme wrote:
On Fri, 2006-02-24 at 21:39 +1100, Rob Mueller wrote:
When I shut down Cyrus cleanly, which of the files in /var/lib/cyrus/db
can be deleted safely along with deliver.db then?
FYI, we're using 2.3 and have:
duplicate_db: berkeley-nosync
On 2006-02-24 11:39:08 -0500 Henrique de Moraes Holschuh
[EMAIL PROTECTED] wrote:
On Fri, 24 Feb 2006, Igor Brezac wrote:
This is really not neccassry unless the berkeley database is
corrupt. Use
'db_recover' to reset the berkeley environment while cyrus server is
not
running.
Cyrus
On Fri, 24 Feb 2006, Igor Brezac wrote:
This is really not neccassry unless the berkeley database is corrupt.
Use 'db_recover' to reset the berkeley environment while cyrus server is
not running.
Cyrus itself attempts to db_recover at startup. Or at least it used to...
It is the reason why
On Fri, 24 Feb 2006, Henrique de Moraes Holschuh wrote:
On Fri, 24 Feb 2006, Igor Brezac wrote:
This is really not neccassry unless the berkeley database is corrupt.
Use 'db_recover' to reset the berkeley environment while cyrus server is
not running.
Cyrus itself attempts to db_recover at
On Fri, 24 Feb 2006, Igor Brezac wrote:
It is *much* more stable than 4.x. if you're using DB3 from a distro (e.g.
Debian's). But it is slower, though.
The stability of DB3 over DB4 is arguable. OpenLDAP folks will disagree
with you. Also my experience is with Solaris in this regard.
be careful. in general, deleting transactions which haven't been
applied to the database isn't a good solution. but since you're only
using Berkeley for duplicate_db, which is non-critical, it is fine in
your setting.
I don't know anyone who uses BDB for critical DB's in cyrus. They're too
On Sat, 25 Feb 2006 09:59:31 +1100
Rob Mueller [EMAIL PROTECTED] wrote:
We have seen many strange problems with BDB over the years. It's taken quite
a bit of fiddling of /var/imap/db/DB_CONFIG values to get a BDB environment
that will run stably over extended periods and loads and on large
Hello there,
I'm running Debian Sarge with Cyrus 2.1.18 on an IBM xSeries Dual-Xeon with
8GB RAM and 450GB disks (ServeRaid controller, RAID5 w/ hot-spare). The
machine serves 22000 accounts (mostly POP3, ca. 250 IMAP users) and has been
running happily without any notable load for a year.
When
On 2/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I've run cyrreconstruct. I've wandered through the mailing list archive and
found countless posts mentioning DB errors, but no real solution.
Documentation seems to be outdated, wrong, or non-existant. I feel lost.
Is there *any* way to
Hello there,
I'm running Debian Sarge with Cyrus 2.1.18 on an IBM xSeries Dual-Xeon
with
8GB RAM and 450GB disks (ServeRaid controller, RAID5 w/ hot-spare). The
machine serves 22000 accounts (mostly POP3, ca. 250 IMAP users) and has
been
running happily without any notable load for a year.
15 matches
Mail list logo
