improvements and corrections in the upgrade-documentatin
I recently upgraded from 2.0.16 to cyrus 2.2 and first followed the offical upgrade-document at http://cyrusimap.web.cmu.edu/imapd/install-upgrade.html This document has several serious flaws. neither the recommended rehash works as proposednor could I convert the mailboxes.db in the recommended way. As I found many other people in various forums that have the same problems I put up a webpage that lists alternate ways: http://www.goldfisch.at/knowwiki/migrate_cyrus Maybe it would be helpful to put a link to this document in the official upgrade-document or just copy the relevant parts there, so other migrating-people will have easier task in migrating. best, peter -- mag. peter pilsl - goldfisch.at IT-Consulting Tel: +43-650-3574035 Tel: +43-1-8900602 Fax: +43-1-8900602-15 skype: peter.pilsl [EMAIL PROTECTED] www.goldfisch.at Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: cyr_expire SIGSEGV
Hi again!
I compiled a cyr_expire with debug symbols... the backtrace looks like:
#0 process_records (mailbox=0xbfb1786c, newindex=0x9558f68,
index_base=0xb66f9000 Address 0xb66f9000 out of bounds, exists=65,
deleted=0x9559158, numdeleted=0xbfb14794, quotadeleted=0xbfb14768,
numansweredflag=0xbfb14790, numdeletedflag=0xbfb1478c,
numflaggedflag=0xbfb14788, newcache=0x9558e00,
new_cache_total_size=0xbfb14780, expunge_fd=-1, last_offset=0,
decideproc=0x804cc10 expire_cb, deciderock=0xbfb184e4, expunge_flags=2)
at mailbox.c:1932
1932cacheitem = CACHE_ITEM_NEXT(cacheitem);
#1 0x080532d3 in mailbox_expunge (mailbox=0xbfb1786c, decideproc=0x804cc10
expire_cb, deciderock=0xbfb184e4, flags=Variable flags is not
available.) at mailbox.c:2308
#2 0x0804cb50 in expire (name=0xbfb17d9d user.mxx.Trash,
matchlen=22, maycreate=1, rock=0xbfb184e4) at cyr_expire.c:224
#3 0x0805aa15 in find_cb (rockp=0xbfb18070, key=0xb69881b4 Address
0xb69881b4 out of bounds, keylen=22, data=0xb69881d0 Address 0xb69881d0
out of bounds, datalen=34) at mboxlist.c:2035
#4 0x0808efce in myforeach (db=0x9558240, prefix=0xbfb180b2 *, prefixlen=0,
goodp=0x805b480 find_p, cb=0x805a880 find_cb, rock=0xbfb18070,
tid=0x0) at cyrusdb_skiplist.c:989
#5 0x08058082 in mboxlist_findall (namespace=0x0, pattern=0xbfb18510 *,
isadmin=1, userid=0x0, auth_state=0x0, proc=0x804c7d0 expire,
rock=0xbfb184e4) at mboxlist.c:2227
#6 0x0804cfa7 in main (argc=6, argv=Cannot access memory at address 0x4
It seems that cyr_expire only crashes on folders that where touched by
ipurge before.
I've
purgetrashcmd=ipurge -fX -d 31 user.*.Trash at=0200
purgejunk cmd=ipurge -fX -d 60 user.*.Junk at=0300
running before cyr_expire (at=0400)
Every time I look into a folder which causes cyr_expire to coredump I find eg
...
-rw--- 1 cyrus mail4 Jan 23 02:00 cyrus.cache
-rw--- 1 cyrus mail 124 Jan 23 13:31 cyrus.cache.NEW
... a cyrus.cache.NEW file that is larger then the old one.
Putting a debug printf in the loop
for (cache_ent = 0; cache_ent NUM_CACHE_FIELDS; cache_ent++) {
cacheitem = CACHE_ITEM_NEXT(cacheitem);
}
... shows that cache_ent always is 0 if the crash occures, so it seems that
cacheitembegin = cacheitem = mailbox-cache_base + cache_offset;
is invalid at that moment.
Regards, Wolfgang Breyha
--
Wolfgang Breyha [EMAIL PROTECTED] | http://www.blafasel.at/
Vienna University Computer Center | Austria
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
vacation: how to view the responded list?
Hello, I wonder if there is a way to view the list of already responded addresses when a sieve/vacation script is active on a mailbox. I've bee googling around for a couple of hours without success. I use cyrus on a Kolab server. Regards, -- Olivier Delemar Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: vacation: how to view the responded list?
Olivier Delemar wrote: Hello, I wonder if there is a way to view the list of already responded addresses when a sieve/vacation script is active on a mailbox. I've bee googling around for a couple of hours without success. I use cyrus on a Kolab server. Not easily. The data you're looking for is in deliver.db, but there isn't any tool available to view it. -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: improvements and corrections in the upgrade-documentatin
peter pilsl wrote: I recently upgraded from 2.0.16 to cyrus 2.2 and first followed the offical upgrade-document at http://cyrusimap.web.cmu.edu/imapd/install-upgrade.html This document has several serious flaws. neither the recommended rehash works as proposednor could I convert the mailboxes.db in the recommended way. As I found many other people in various forums that have the same problems I put up a webpage that lists alternate ways: http://www.goldfisch.at/knowwiki/migrate_cyrus Maybe it would be helpful to put a link to this document in the official upgrade-document or just copy the relevant parts there, so other migrating-people will have easier task in migrating. Could you send a patch against the current documentation that incorporates your changes? -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: The annoyance of repeating Makefiles
Gary Mills wrote: I've noticed for some time that whenever I type `make' in the Cyrus source tree, it always recompiles something. A repeated make should evenually stop compiling but this one never does. The worst offenders are the various perl Makefiles which rebuild Makefile from Makefile.PL every time, instead of only doing it when it's out of date. This I'm not a Perl guy, so I don't know if this is necessary or not. causes the perl modules to be recompiled. As well, imap/Makefile recreates xversion.h each time, resulting in more recompiles. We recreate xversion.h (and imapd as a result) so we get an accurate CVS timestamp in imapd for version reporting. This behavior is annoying because I build the Cyrus software on a development server but then install it on other servers where there is no compiler and the source tree is mounted read-only. This breaks `make install', which should only install things, not recompile them. Can this be fixed, or am I condemned to hack Makefiles myself? A 'make install' shouldn't compile anything if all of the generated files already exist. I would consider this a bug and would gladly accept a patch which fixes this behavior. -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: The annoyance of repeating Makefiles
On Tue, Jan 23, 2007 at 09:50:32AM -0500, Ken Murchison wrote: Gary Mills wrote: I've noticed for some time that whenever I type `make' in the Cyrus source tree, it always recompiles something. A repeated make should evenually stop compiling but this one never does. The worst offenders are the various perl Makefiles which rebuild Makefile from Makefile.PL every time, instead of only doing it when it's out of date. This I'm not a Perl guy, so I don't know if this is necessary or not. The problem is that Makefile.PL is not really a Makefile. It's run by perl to create the Makefile. I suppose that that should be done by the configure step, not by the compile step. causes the perl modules to be recompiled. As well, imap/Makefile recreates xversion.h each time, resulting in more recompiles. We recreate xversion.h (and imapd as a result) so we get an accurate CVS timestamp in imapd for version reporting. I'm not a CVS guy, but there must be a better way to accomplish this without causing a recompile. This behavior is annoying because I build the Cyrus software on a development server but then install it on other servers where there is no compiler and the source tree is mounted read-only. This breaks `make install', which should only install things, not recompile them. Can this be fixed, or am I condemned to hack Makefiles myself? A 'make install' shouldn't compile anything if all of the generated files already exist. I would consider this a bug and would gladly accept a patch which fixes this behavior. Is there a release coming soon, perhaps to fix the core dump that we heard about? If so, I'll use that distribution to work on a patch. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: The annoyance of repeating Makefiles
Gary Mills wrote: On Tue, Jan 23, 2007 at 09:50:32AM -0500, Ken Murchison wrote: Gary Mills wrote: I've noticed for some time that whenever I type `make' in the Cyrus source tree, it always recompiles something. A repeated make should evenually stop compiling but this one never does. The worst offenders are the various perl Makefiles which rebuild Makefile from Makefile.PL every time, instead of only doing it when it's out of date. This I'm not a Perl guy, so I don't know if this is necessary or not. The problem is that Makefile.PL is not really a Makefile. It's run by perl to create the Makefile. I suppose that that should be done by the configure step, not by the compile step. Sounds reasonable to me. causes the perl modules to be recompiled. As well, imap/Makefile recreates xversion.h each time, resulting in more recompiles. We recreate xversion.h (and imapd as a result) so we get an accurate CVS timestamp in imapd for version reporting. I'm not a CVS guy, but there must be a better way to accomplish this without causing a recompile. If there is, I'd love for somebody to tell me. We look at the CVS timestamp of ALL of the source files and then put that into xversion.h This behavior is annoying because I build the Cyrus software on a development server but then install it on other servers where there is no compiler and the source tree is mounted read-only. This breaks `make install', which should only install things, not recompile them. Can this be fixed, or am I condemned to hack Makefiles myself? A 'make install' shouldn't compile anything if all of the generated files already exist. I would consider this a bug and would gladly accept a patch which fixes this behavior. Is there a release coming soon, perhaps to fix the core dump that we heard about? If so, I'll use that distribution to work on a patch. There will be a release as soon as I track down and fix the bug that causes mupdate to randomly spin in 2.3. -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: vacation: how to view the responded list?
Olivier Delemar wrote: On Tue, 23 Jan 2007 09:45:58 -0500, Ken Murchison [EMAIL PROTECTED] wrote: Olivier Delemar wrote: Hello, I wonder if there is a way to view the list of already responded addresses when a sieve/vacation script is active on a mailbox. I've bee googling around for a couple of hours without success. I use cyrus on a Kolab server. Not easily. The data you're looking for is in deliver.db, but there isn't any tool available to view it. Thank you so much Ken. I'm not afraid about perl. Is it a Berkeley DB file? I would be happy if I could make a small tool I could share. You could also try the cyr_dbtool written by Fastmail.fm. This tool will appear in Cyrus 2.3.8 http://cyrus.brong.fastmail.fm/cyrus-dbtool-2.3.7.diff -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: vacation: how to view the responded list?
On Tue, 23 Jan 2007 09:45:58 -0500, Ken Murchison [EMAIL PROTECTED] wrote: Olivier Delemar wrote: Hello, I wonder if there is a way to view the list of already responded addresses when a sieve/vacation script is active on a mailbox. I've bee googling around for a couple of hours without success. I use cyrus on a Kolab server. Not easily. The data you're looking for is in deliver.db, but there isn't any tool available to view it. Thank you so much Ken. I'm not afraid about perl. Is it a Berkeley DB file? I would be happy if I could make a small tool I could share. -- Olivier Delemar Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
