Cyrus 2.2 imapd in AMD64
in [Debian]
|
Prev: python-twisted-core not getting updated on i386, but is updated on amd64 [was Re: Increasing number of conflicts]
Next: Why are there no latest books written for Debian systems?
From: Carlos Bergero on 26 Apr 2010 15:10 El 22/04/10 20:50, Carlos Bergero escribió: > Hi there list, got some trouble running a cyrus server, actually I > have an old setup running in Etch i386 without any trouble, virtual > mail server and all pgsql setup for backend and postfix for MTA, all > sweat. I installed a new server, better hardware, using AMD64 dist, as > Etch is going to be out of security, I copy everithing but the cyrus > is not properly working. I cant conect to the imap port or use imtest, > to check users, when i start server first cyr_expire and then > tls_prune consume lots of time doing not shure what, and i get the > following syslog and kern.log error: > > Apr 22 18:48:08 darwin kernel: [6121490.275489] ctl_cyrusdb[18309] > general protection ip:7fecdaef0f30 sp:7fffc46d9380 error:0 in > libdb-4.2.so[7fecdae4e000+ea000] > Apr 22 19:12:49 darwin kernel: [6122984.242061] ctl_cyrusdb[18505]: > segfault at 7f584401cefc ip 7f0a429acf30 sp 7fffb28b3cf0 error 4 in > libdb-4.2.so[7f0a4290a000+ea000] > Apr 22 19:13:48 darwin kernel: [6123046.804454] ctl_cyrusdb[18594]: > segfault at 7f7805960efc ip 7f2a042f0f30 sp 7fff32ae8440 error 4 in > libdb-4.2.so[7f2a0424e000+ea000] > Apr 22 19:28:52 darwin kernel: [6124020.255192] ctl_cyrusdb[18881]: > segfault at 7f8302309efc ip 7f3500c99f30 sp 7fff8d1ed6e0 error 4 in > libdb-4.2.so[7f3500bf7000+ea000] > Apr 22 19:57:43 darwin kernel: [6125775.477974] ctl_cyrusdb[19100] > general protection ip:7fdb78441f30 sp:7ffff5879430 error:0 in > libdb-4.2.so[7fdb7839f000+ea000] > Apr 22 20:17:05 darwin kernel: [6127022.816744] ctl_cyrusdb[19571] > general protection ip:7fe3cd7aaf30 sp:7fff03057fe0 error:0 in > libdb-4.2.so[7fe3cd708000+ea000] > > which is wierd! > > After a while or if I kill this process cyrmaster starts but the re is > no way to conect to the imap server. Configuration files are the same > in both servers, etch and lenny its just not working in lenny though > packages looks to be the same. > This is the cyrus.conf file: > > > > Any clues about what could be wrong? > > Cheers, > Carlos > > Apparently for what i read in list and in web pages/lists/readme it might be a compatibility problem in Berkeley DB use by Cyrus. For the record I inherit this system in a Unstable Testing server, in production, and had to do an emergency migration to Etch Old Stable, about a year ago(stable by then). Now I'm moving it to a newer server in Lenny Stable and find my self unable to start the cyrus process properly, apparently the server runs a series of checks in this DB, tls_sessions.db an deliver.db, at start time and in different crons, which get stall while running. So far I haven't been able to fix the problem but at least it seams the issue came that way, which is something. The mentioned DB has the following file format: ../tls_sessions.db: Berkeley DB (Btree, version 8, native byte-order) ../deliver.db: Berkeley DB (Btree, version 8, native byte-order) and there a a couple of cyrus DB files which readme upgrade ask to migrate with a cyrus tool which is not working atm, ../mailboxes.db: Cyrus skiplist DB (which it has a different name simply mailboxes, without the .db extension) ../annotations.db: Cyrus skiplist DB (which is not mentioned in the tutorial) So far im focused in trying to get this DB to the proper format version 9 in the standard Lenny install, and see what happens, without much success. If I manage to work it out ill post the process int list. If anyone has a better clue ill appreciate it :) Sincerely, Carlos -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD5E41E.80702(a)fcien.edu.uy
From: Kris Deugau on 26 Apr 2010 17:40 Carlos Bergero wrote: > Apparently for what i read in list and in web pages/lists/readme it > might be a compatibility problem in Berkeley DB use by Cyrus. Mmm, possible but IME BDB has an unfortunate tendency to create files that are not cross-version-compatible. Upstream supposedly provides an upgrade/conversion script/binary (not sure which one), but I've never found it, and it may be in a -utils package. > So far im focused in trying to get this DB to the proper format version > 9 in the standard Lenny install, and see what happens, without much > success. BDB and other binary hash files are typically discardable and can be regenerated from a plaintext source, IME. See if you can find that source, and the process or script that regenerates the live BDB files. -kgd -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD60148.4000907(a)vianet.ca
From: Carl Johnson on 26 Apr 2010 19:00 Carlos Bergero <rak(a)fcien.edu.uy> writes: --snip-- > Apparently for what i read in list and in web pages/lists/readme it > might be a compatibility problem in Berkeley DB use by Cyrus. --snip-- > So far im focused in trying to get this DB to the proper format > version 9 in the standard Lenny install, and see what happens, without > much success. > If I manage to work it out ill post the process int list. > If anyone has a better clue ill appreciate it :) Have you looked at the db4.x-util packages, for whatever version of library you have? The db4.6-util package contains a program called db4.6-upgrade which might do what you want. There are other version of db-util, so get whichever one matches your current library and try it on a *copy* to see if it does what you want. -- Carl Johnson carlj(a)peak.org -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/8739yhx1yg.fsf(a)cjlinux.localnet
From: Henrique de Moraes Holschuh on 1 May 2010 12:00
On Mon, 26 Apr 2010, Carlos Bergero wrote: > ./tls_sessions.db: Berkeley DB (Btree, version 8, native byte-order) > ./deliver.db: Berkeley DB (Btree, version 8, native byte-order) > and there a a couple of cyrus DB files which readme upgrade ask to > migrate with a cyrus tool which is not working atm, > ./mailboxes.db: Cyrus skiplist DB (which it has a different name > simply mailboxes, without the .db extension) > ./annotations.db: Cyrus skiplist DB (which is not mentioned in the > tutorial) > So far im focused in trying to get this DB to the proper format > version 9 in the standard Lenny install, and see what happens, > without much success. db*_upgrade will upgrade (NOT DOWNGRADE) a berkeley database. Run it from the main environment directory. It is in the db*-util packages. Use the correct target version (for cyrus, see the package dependency list to know which libdb it uses). Just delete tls_sessions.db. It is the TLS session cache. You can consider deleting deliver.db. It is the cache used for duplicate suppression and to avoid sending vacation messages to the same recipient twice. There will be very little harm done (if any) should you delete it. Consider reading the documentation for berkeley DB, especially the stuff prepared by OpenLDAP and samba (look in their web pages). Screw that up, and your performance goes downhill. Consider reading the archives of the cyrus users ML, hunt down from any posts from @fastmail.fm and read them. They _REALLY_ know their stuff. All skiplist DBs are auto-upgraded by cyrus on access. If one wasn't, chances are it is corrupt and you have a big problem. After you manage to start cyrus, run cyrquota and cyrreconstruct over *ALL* mailboxes. I mean *ALL* of them. And this _will_ take time. You could do it with the system in use, but since it is a safety measure to insure there is no inconsistent data, well, it is best done before any read or write access is done to the mailboxes. And do remember cyrus has databases stored in the user dirs as well. Debian packages should have them skiplist or plaintext, which don't require manual intervention, but check it (seen database). Sieve requires conversion of _all_ scripts on all spools. Look for the massievec script and run it on every sieve script. This is _all_ in the cyrus documentation, although probably not organized like that... -- "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 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100501155315.GA24313(a)khazad-dum.debian.net |