Hi everyone,
Paul Boven wrote:
If I build cyrus against the old version (4.1.25), it runs great. If I
build it against 4.4.20, it doesn't want to start. Even though I've
changed tlscache_db and duplicate_db to 'skiplist' in the imapd.conf and
removed those db-files from the system, so it shouldn't even be using
Berkeley-db anymore, with all databases being skiplist.
Starting with a clean /var/imap, I can start the newly compiled Cyrus,
so it has to do with whatever is left in /var/imap/db from the old
Berkeley version.
I've also done a db_upgrade in /var/imap using the 4.4.20 db_upgrade
version, but the Cyrus with the 4.4.20 Berkeley libs still won't start.
I'd welcome any suggestions on how to proceed and make this into a
working mail-server again. (Don't worry, this is only the testbed - the
really scary stuff is yet to come).
Progress made since:
I've tried to build a Cyrus without any Berkeley by specifying
'--without-bdb' - for that, I had to comment out a fixed '#include
<db.h>' in lib/auth_pts.h. But that only resulted in this error message
when starting up: "Fatal error: cyrusdb backend berkeley not supported".
Other people seem to have managed to go without Berkeley, but so far I
haven't - and as Berkely has better performance for the deliver.db and
tls_sessions.db, that is not the preferred workaround anyway.
I've started building cyrus-imapd-2.2.13 - the Cyrus homepage still
lists 2.2.12 as the 'current' version, but is apparently outdated a bit.
In another posting to this list, Andrew Morgan hinted that "Cyrus
v2.2.12 and older will not work with Berkeley DB 4.3+ without a patch".
With 2.2.13, at least I get a meaningful error out of Berkeley when I
start Cyrus:
DBERROR db4: Skipping log file /var/imap/db/log.0000000001: historic log
version 7
DBERROR db4: /var/imap/db/log.0000000002: log file open failed: No such
file or directory
DBERROR db4: PANIC: No such file or directory
Running db_recover from Berkeley4.4.20 gave me essentially the same errors.
In the end, I figured it apparently doesn't care about log.00000001, so
I moved it aside. This time, it also stopped looking for log.00000002
and recovered succesfully. And now Cyrus works again!
Before I even want to consider doing this kind of surgery on any of my
production Cyrus servers, I'd like to know what would have been in
log.00000001 - what risks do I run when removing it?
Regards, Paul Boven.
----
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
