Re: ctl_cyrusdb: impact of increasing period
Marc G. Fournier wrote: I'm still having issues with ctl_cyrusdb 'hanging', as I've reported before ... running Cyrus-IMAPd 2.2.8 with DB3 ... Right now, cyrus.conf is set to run it every 30 minutes: checkpointcmd=ctl_cyrusdb -c period=30 What sort of impact would there be in changing that to be less frequent? Say, once or twice a day instead? The biggest impact would be a slower Cyrus startup (ctl_cyrusdb -r). The more frequent the checkpoints, the quicker the recovery. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp --- 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
Mailbox migration tools
Hi I just migrated from standard unix mailbox to cyrus-imap. The migration tools distributed with cyrus-imap somewhat obscure and largely undocu- mented so I ended up writing my own, which I hope are better and I would like to make available for anyone who might find them usefull. They are here: http://www.daemonsecurity.com/src/cyrus-imap.tgz Some reasons I find them better: 1) Supports virtual domains 2) Can be run multiple times, posibility of reducing downtime 3) Easier to tweak 2: On first run, let your MTA keep delivering mail to the local mailbox, then shut it down. On second run, the migration script will only trans- fer new mails, this is considerably faster. 3: This is ofcourse partly personal because I wrote it. But, there is not inherent scripts calling scripts calling scripts etc. Since I have migrated, I have lost interest in further tweaking, bug- reports and suggestions are welcome. Cheers, Erik --- 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
Re: Cyrus Murder: Backend causes corrupted mailbox list database
Bernd Helmle wrote: [ Sorry for reposting this mail, but it seems to me that the first one didn't reach the list. ] we're currently experimenting with the Cyrus Murder to build a IMAP server cluster infrastructure. I had setup a master mupdate server, a backend and frontend server. The server configuration looks like below: Server A = master mupdate server | Server B = backend server with mupdate slave daemon | Server C = frontend server with all proxies enabled The frontend should have the mupdate slave, NOT the backend. The backends should only know about the mailboxes that they contain individually. The frontends need to know about all mailboxes, hence the need for the mupdate slave. All works fine, the backend synchronizes with the master correctly and the frontend servers works as expected. However, if i shutdown and restart the Cyrus IMAP server on the backend, _all_ mailboxes located on this backend becames unaccessable (when connecting through both, the backend and frontend servers). The following can be found in the logs: Aug 26 15:07:28 fritz imap[9894]: login: td9091af2.pool.terralink.de [217.9.26.242] test CRAM-MD5 User logged in Aug 26 15:07:28 fritz imap[9894]: IOERROR: opening fritz!fritz!fritz!default/cyrus.header: No such file or directory Notice the weird mailbox location path. Issueing the ctl_mboxlist -d command on the backend shows this: fritz:~# su cyrus -c /usr/sbin/ctl_mboxlist -d user.test fritz!fritz!fritz!default testlrswipcda user.test.test2 fritz!fritz!fritz!default testlrswipcda The mupdate master server shows the same. Synchronization after restarting the backend shows no errors. Cyrus Version is Cyrus IMAP4 v2.2.8-Debian-2.2.8-1 TIA -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp --- 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
Re: Cyrus Murder: Backend causes corrupted mailbox list database
--On Sonntag, August 29, 2004 08:06:05 -0400 Ken Murchison [EMAIL PROTECTED] wrote: The frontend should have the mupdate slave, NOT the backend. The backends should only know about the mailboxes that they contain individually. The frontends need to know about all mailboxes, hence the need for the mupdate slave. Err, that was the point. Thanks for the hint! -- Bernd --- 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
ctl_cyrusdb hanging in libcyrus_init ...
First, I'm running Cyrus IMAPd 2.2.8 currently ...
Trying to narrow down *why* this is happening, I started to add a bunch of
syslog() statements to global.c, to try and narrow things down ... I'm to
the point that I'm in 'cyrusdb_init()', with code that looks like:
void cyrusdb_init()
{
int i, r;
char dbdir[1024];
const char *confdir = libcyrus_config_getstring(CYRUSOPT_CONFIG_DIR);
int initflags = libcyrus_config_getint(CYRUSOPT_DB_INIT_FLAGS);
strcpy(dbdir, confdir);
strcat(dbdir, FNAME_DBDIR);
for(i=0; cyrusdb_backends[i]; i++) {
syslog(LOG_NOTICE, - cyrusdb_init; %s, cyrusdb_backends[i]-name);
r = (cyrusdb_backends[i])-init(dbdir, initflags);
if(r) {
syslog(LOG_ERR, DBERROR: init() on %s,
cyrusdb_backends[i]-name);
}
}
}
Below is from the logs ... I have a process that checks for 2 ctl_cyrusdb
processes running, and if so, it does a restart on the master process ...
in this case, process 76671 and 81190 have hung up at cyrus_init:
berkeley, while 82601 shows a clean run through after the restart:
Aug 29 11:45:08 affronter ctl_cyrusdb[76671]: - configure libcyrus
Aug 29 11:45:08 affronter ctl_cyrusdb[76671]: - libcyrus_init begin
Aug 29 11:45:08 affronter ctl_cyrusdb[76671]: - cyrusdb_init; berkeley
Aug 29 12:15:08 affronter ctl_cyrusdb[81190]: - configure libcyrus
Aug 29 12:15:08 affronter ctl_cyrusdb[81190]: - libcyrus_init begin
Aug 29 12:15:08 affronter ctl_cyrusdb[81190]: - cyrusdb_init; berkeley
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - configure libcyrus
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - libcyrus_init begin
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - cyrusdb_init; berkeley
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - cyrusdb_init; berkeley-nosync
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - cyrusdb_init; flat
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - cyrusdb_init; skiplist
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - cyrusdb_init; quotalegacy
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - libcyrus_init end
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: - end cyrus_init
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: recovering cyrus databases
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: skiplist: recovered
/var/spool/imap/mailboxes.db (1 record, 336 bytes) in 0 seconds
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: skiplist: recovered
/var/spool/imap/annotations.db (0 records, 144 bytes) in 0 seconds
Aug 29 12:30:06 affronter ctl_cyrusdb[82601]: done recovering cyrus databases
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - configure libcyrus
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - libcyrus_init begin
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - cyrusdb_init; berkeley
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - cyrusdb_init; berkeley-nosync
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - cyrusdb_init; flat
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - cyrusdb_init; skiplist
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - cyrusdb_init; quotalegacy
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - libcyrus_init end
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: - end cyrus_init
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: checkpointing cyrus databases
Aug 29 12:30:07 affronter ctl_cyrusdb[82612]: done checkpointing cyrus databases
I'm still working on 'moving in' towards the culprit ... but does anyone
know why the above would happen?
Will post more as I get more ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---
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
FC2 and DB4 rebuild with DB4 Patch
FC2 and Cyrus-IMAPD-2.2.8 I'm starting to build up a new IMAP server on FC2 and ran into my first snag. I downloaded src rpms from Simon Matters site and grabbed the db4.spec.patch file to rebuild db4. The problem is that this patch file doesn't complete successfully on db4-4.2.52 version that is on FC2. I looked back and it seemed that the patch was to fix something about db4 on Redhat distros. Was this fixed in db4-4.2.52? I guess I could try but didn't want to waste time if it wont work. --- 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
Re: INBOX issue
Alexander Dalloz [EMAIL PROTECTED] wrote .. Am Sa, den 28.08.2004 schrieb Michael Ballard um 23:28: define(`CYRUSV2_MAILER_ARGS', `FILE /var/lib/imap/socket/lmtp')dnl [EMAIL PROTECTED]... Connecting to /var/imap/socket/lmtp via cyrusv2... Could not connect to socket /var/imap/socket/lmtp: Connection refused by localhost You see the difference between the paths? Don't know what webmin does or not does, but I never took it worth handling any Sendmail setup. Here it obviously did not change the path set by the CYRUSV2_MAILER_ARGS string but keeps what's in the cyrusv2.m4 macro file. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 00:22:52 up 8 days, 20:05, load average: 0.70, 0.39, 0.19 --- 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 /var/imap/socket/lmtp IS where the lmtp socket it, so I changed that in sendmail.mc...but I still have the exact same results... I think there's either something seriously wrong with my setup, or something extremely simple
Re: INBOX issue
Am So, den 29.08.2004 schrieb Michael Ballard um 20:19: define(`CYRUSV2_MAILER_ARGS', `FILE /var/lib/imap/socket/lmtp')dnl [EMAIL PROTECTED]... Connecting to /var/imap/socket/lmtp via cyrusv2... Could not connect to socket /var/imap/socket/lmtp: Connection refused by localhost You see the difference between the paths? Don't know what webmin does or not does, but I never took it worth handling any Sendmail setup. Here it obviously did not change the path set by the CYRUSV2_MAILER_ARGS string but keeps what's in the cyrusv2.m4 macro file. /var/imap/socket/lmtp IS where the lmtp socket it, so I changed that in sendmail.mc...but I still have the exact same results... I know that the lmtp socket is in that path on FC2. But you did not change Sendmail with a proper sendmail.cf to point to that socket. I think there's either something seriously wrong with my setup, or something extremely simple I suggest you don't use webmin for Sendmail setups. Edit the sendmail.mc file as I did show you and run make -C /etc/mail and service sendmail restart. Don't let webmin touch the Sendmail config files. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 20:36:30 up 9 days, 16:19, load average: 0.04, 0.13, 0.10 --- 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
sievec core dumps when hitting 'address' or 'envelope'
We ran into a problem on Tru64 where the sieve compiler was core dumping
if it tried to compile a script that used 'address' or 'envelope' in it.
For example, the following script would core dump sievec:
if address :contains To [EMAIL PROTECTED] {
stop;
}
Changing 'address' to 'header' would work just fine.
I tracked it down to a header file, tree.h. Basically, there is a union
defined inside the 'Test' structure that itself defines a few structures
that would share the same memory space (so to speak... if you understand
C programming, then you should understand what unions are). The problem
is that two of the structures defined many of the same variables as each
other, but in different orders...
For example, the first structure in the union declares A, B, then C, but
the second structure in the union declares A, C, then B.
This shouldn't normally be a problem, but on Tru64 5.x, it certainly is.
I am not sure if it is a weirdness with 'cc', or if it is something deeper.
The code compiles and without warnings, but it core dumps at runtime.
Simply changing the order in one structure or the other to match solves
the problem nicely.
This could very well be related to the following bug:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2476
I submitted a patch, which I will include here, that should fix it. It
is a *very* small patch :)
Scott
--
+---+
Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/
UNIX Systems Engineer mailto:[EMAIL PROTECTED]
ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+---+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
SIEVE_UNION.patch
Description: Binary data
pgpjsabmK0EnL.pgp
Description: PGP signature
Re: sievec core dumps when hitting 'address' or 'envelope'
Probably has to do with 64 bit alignment and pointers versus 32 bit
alignment and pointers. by reordering the int/pointer pair the union
becomes not so much a union in the sense that may be meant for it. didn't
look into it deeply at all myself, but it would ppear that the machine
code/variable space for each of the compiled versions of those mis-ordered
unions is quite different on 64 bit platforms.
--On Monday, August 30, 2004 00:42 -0400 Scott Adkins [EMAIL PROTECTED]
wrote:
We ran into a problem on Tru64 where the sieve compiler was core dumping
if it tried to compile a script that used 'address' or 'envelope' in it.
For example, the following script would core dump sievec:
if address :contains To [EMAIL PROTECTED] {
stop;
}
Changing 'address' to 'header' would work just fine.
I tracked it down to a header file, tree.h. Basically, there is a union
defined inside the 'Test' structure that itself defines a few structures
that would share the same memory space (so to speak... if you understand
C programming, then you should understand what unions are). The problem
is that two of the structures defined many of the same variables as each
other, but in different orders...
For example, the first structure in the union declares A, B, then C, but
the second structure in the union declares A, C, then B.
This shouldn't normally be a problem, but on Tru64 5.x, it certainly is.
I am not sure if it is a weirdness with 'cc', or if it is something
deeper.
The code compiles and without warnings, but it core dumps at runtime.
Simply changing the order in one structure or the other to match solves
the problem nicely.
This could very well be related to the following bug:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2476
I submitted a patch, which I will include here, that should fix it. It
is a *very* small patch :)
Scott
--
+---+
Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/
UNIX Systems Engineer mailto:[EMAIL PROTECTED]
ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+---+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
--
Undocumented Features quote of the moment...
It's not the one bullet with your name on it that you
have to worry about; it's the twenty thousand-odd rounds
labeled `occupant.'
--Murphy's Laws of Combat
---
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
