xfermailbox in unified murder config
Hi, is there any success in transferring mailbox to a different server in unified murder config ? I got error : Could not move mailbox: user.abc, LOCALCREATE failed user.abc is in server1, I tried to xfer it to server2. I'm wondering the LOCALCREATE user.abc in server2 failed because of mailbox already exists This message was sent using IMP, the Internet Messaging Program. 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: DB4 downgrade
Simon Matter wrote: Simon Matter wrote: Because of the sudden end-of-life of Fedora Core 4, I'm moving my mail server from FC4 to a CentOS 4.4 box. FC4 uses DB4 4.3.27. CentOS 4.4 uses DB4 4.2.52. What's the best way for me to downgrade the Cyrus DBs for this migration? Convert all BerkeleyDBs on the FC4 box to skiplist and then migrate to the new server/installation. Skiplist doesn't change from version to version so you don't have that problem anymore. Sounds good. It's sufficient just to use the file command to see which of the db files are already skiplist and which are Berkeley DB? Yes, that should be okay. For me it looks like this: [EMAIL PROTECTED] imap]# file /var/lib/imap/*.db /var/lib/imap/annotations.db: Cyrus skiplist DB /var/lib/imap/deliver.db: Cyrus skiplist DB /var/lib/imap/mailboxes.db:Cyrus skiplist DB /var/lib/imap/tls_sessions.db: Cyrus skiplist DB One more tip: You may want to remove all data from the db dirs because there may still be some files from the BerkeleyDB and they can lead to error messages, which are in fact not real cyrus errors. On such a migratin I usually do this after rsyncing: rm -rvf /var/lib/imap/db/* /var/lib/imap/db.* I finally got a window of scheduled downtime to test this, and I'm having problems. Here's what I did: # /etc/init.d/cyrus-imapd stop # db_checkpoint -v -1 -h /var/lib/imap/db # db_recover -v -h /var/lib/imap/db # rm db/* # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/deliver.db berkeley /var/lib/imap/deliver.db.skip skiplist # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/tls_sessions.db berkeley /var/lib/imap/tls_sessions.db.skip skiplist # mv deliver.db.skip deliver.db ; mv tls_sessions.db.skip tls_sessions.db # chown cyrus:mail tls_sessions.db deliver.db # /etc/init.d/cyrus-imapd start At this point, the log explodes with messages along the lines of: Dec 11 06:11:53 ajax imaps[1394]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imaps pid 1394 in READY state: terminated abnormally Dec 11 06:11:53 ajax master[32203]: service lmtpunix pid 1397 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1395]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1395]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imap pid 1395 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1399]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1399]: DBERROR: critical database situation Dec 11 06:11:53 ajax imaps[1400]: DBERROR A : db4 Dec 11 06:11:53 ajax imaps[1400]: DBERROR: critical database situation Any ideas on why this is going on? I did notice that /var/lib/imap/rpm/db.cfg.cache has entries along the lines of: CONFIG_DB_DUPLICATE=berkeley CONFIG_DB_MBOX=skiplist CONFIG_DB_SEEN=skiplist CONFIG_DB_SUBS=flat CONFIG_DB_TLS=berkeley CONFIG_DB_ANNOTATION=skiplist CONFIG_DB_SIEVE=2.2.3 Is there someplace I need to tell imapd that deliver and tls_sessions are now skiplist? I don't see anything in /etc/imapd.conf and /etc/cyrus.conf. Thanks. 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: DB4 downgrade
Simon Matter wrote: Simon Matter wrote: Because of the sudden end-of-life of Fedora Core 4, I'm moving my mail server from FC4 to a CentOS 4.4 box. FC4 uses DB4 4.3.27. CentOS 4.4 uses DB4 4.2.52. What's the best way for me to downgrade the Cyrus DBs for this migration? Convert all BerkeleyDBs on the FC4 box to skiplist and then migrate to the new server/installation. Skiplist doesn't change from version to version so you don't have that problem anymore. Sounds good. It's sufficient just to use the file command to see which of the db files are already skiplist and which are Berkeley DB? Yes, that should be okay. For me it looks like this: [EMAIL PROTECTED] imap]# file /var/lib/imap/*.db /var/lib/imap/annotations.db: Cyrus skiplist DB /var/lib/imap/deliver.db: Cyrus skiplist DB /var/lib/imap/mailboxes.db:Cyrus skiplist DB /var/lib/imap/tls_sessions.db: Cyrus skiplist DB One more tip: You may want to remove all data from the db dirs because there may still be some files from the BerkeleyDB and they can lead to error messages, which are in fact not real cyrus errors. On such a migratin I usually do this after rsyncing: rm -rvf /var/lib/imap/db/* /var/lib/imap/db.* I finally got a window of scheduled downtime to test this, and I'm having problems. Here's what I did: # /etc/init.d/cyrus-imapd stop # db_checkpoint -v -1 -h /var/lib/imap/db # db_recover -v -h /var/lib/imap/db # rm db/* # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/deliver.db berkeley /var/lib/imap/deliver.db.skip skiplist # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/tls_sessions.db berkeley /var/lib/imap/tls_sessions.db.skip skiplist # mv deliver.db.skip deliver.db ; mv tls_sessions.db.skip tls_sessions.db # chown cyrus:mail tls_sessions.db deliver.db # /etc/init.d/cyrus-imapd start At this point, the log explodes with messages along the lines of: Dec 11 06:11:53 ajax imaps[1394]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imaps pid 1394 in READY state: terminated abnormally Dec 11 06:11:53 ajax master[32203]: service lmtpunix pid 1397 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1395]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1395]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imap pid 1395 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1399]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1399]: DBERROR: critical database situation Dec 11 06:11:53 ajax imaps[1400]: DBERROR A : db4 Dec 11 06:11:53 ajax imaps[1400]: DBERROR: critical database situation Any ideas on why this is going on? I did notice that /var/lib/imap/rpm/db.cfg.cache has entries along the lines of: CONFIG_DB_DUPLICATE=berkeley CONFIG_DB_MBOX=skiplist CONFIG_DB_SEEN=skiplist CONFIG_DB_SUBS=flat CONFIG_DB_TLS=berkeley CONFIG_DB_ANNOTATION=skiplist CONFIG_DB_SIEVE=2.2.3 Is there someplace I need to tell imapd that deliver and tls_sessions are now skiplist? I don't see anything in /etc/imapd.conf and /etc/cyrus.conf. Something is really broken here... First shutdown using 'service cyrus-imapd stop', then put this in /etc/imapd.conf: duplicate_db: skiplist tlscache_db: skiplist Now try to start it up using 'service cyrus-imapd start'. Unfortunately I think the cyrus-imapd package shipped with FC4 has some bugs in the init scripts. I recommend you use my rpms, which are newer and have less bugs. RedHat ships old versions of my rpms which don't include the latest bug fixes. Find the source rpm here: http://www.invoca.ch/pub/packages/cyrus-imapd/ Simon 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: some notes on upgrading from 2.1.15 to 2.2.12
Simon Matter wrote: This may not be too important for anyone any more, I had some weirdness with quotas wehn upgrading from 2.1.15 to 2.2.12. At first I thought that all my quotas were somehow lost during the upgrade. Originally I thought this might have been because I inadvertently left the Cyrus master daemon turned on when I first rebooted the system back to multi-user mode. It seemed as though the quotas.db file, was completely empty after the aborted run of the new version prior to DB conversion. Hmmm hang on, maybe that's also because the old version had been configured to use quotalegacy by default, which are the individual files in /var/quota/?/user.*; but the new version was configured to use a skiplist DB by default, and the actual setting was never present in the config file. Not thinking about the quotalegacy issue (because I was too tired) I simply re-assigned the quotas manually using the cyradm interface, shut down master, then used quota -f to recover the usage numbers. However during recovery I noted some very strange things happening with the quota -f runs. The first time I ran quota -f without any mailboxes then it seemed to whack the usage numbers by a factor of two (I can't remember which way) on the mailboxes where I had already done a test run of quota -f user.USER. I saw things like that more than once and I never figured out what exactly has triggered it and which versions of cyrus were affected. However, I found a general rule which seems important at least it was so when I last had a problem with quotas with 2.3.7: Always make sure that your metadata is clean before using quota -f. If in doubt, run reconstruct first. This seems to also be the case after some upgrades. So for me I'm now always doing a reconstruct before a quota -f. This can takes dozens of hours on large systems but better than having broken quotas for such a long period. Simon et all, Our site had a huge failure (we lost the config directory /var/imap) this weekend. We are now back running with a recovered mailboxes.db en *.sub files for our users (we didn't use reconstruct as that would take to long, 800Gigs of mail). The only thing still lacking is correct quotas. I set the quota for each mailbox to 'none' (to get everything working). Now I want to add a correct quota number. However I can set it with 'sq user.login x'. But requesting the quota gives me: tarzan lq user.rgevaert STORAGE 0/200 (0%) I am sure to have several megabytes. I looks like I have to run the quota program. Before doing it on the full system I would like to run it for my own mailbox. But: Running quota with both the -f option and mailbox-prefix arguments is not recommended. I'm running: name : Cyrus IMAPD version: v2.1.18 2005/02/14 06:45:19 Do you have any ideas what the consequences would be if I ran quota -f user.login on the running system? Thanks in advance, -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office Groep SystemenSystems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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
BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
I'm using the UW mailutil to transfer mailboxes from UW to Cyrus (2.3.7). It uses APPEND, specifically multiappend (single APPEND with multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Do people just tweak their kernels to have some insane number of FDs available in order to compensate for this? Or, do people not use mailutil and instead use something that issues multiple append commands rather than a single append with multiple e- mails? -nik 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: some notes on upgrading from 2.1.15 to 2.2.12
Simon Matter wrote: This may not be too important for anyone any more, I had some weirdness with quotas wehn upgrading from 2.1.15 to 2.2.12. At first I thought that all my quotas were somehow lost during the upgrade. Originally I thought this might have been because I inadvertently left the Cyrus master daemon turned on when I first rebooted the system back to multi-user mode. It seemed as though the quotas.db file, was completely empty after the aborted run of the new version prior to DB conversion. Hmmm hang on, maybe that's also because the old version had been configured to use quotalegacy by default, which are the individual files in /var/quota/?/user.*; but the new version was configured to use a skiplist DB by default, and the actual setting was never present in the config file. Not thinking about the quotalegacy issue (because I was too tired) I simply re-assigned the quotas manually using the cyradm interface, shut down master, then used quota -f to recover the usage numbers. However during recovery I noted some very strange things happening with the quota -f runs. The first time I ran quota -f without any mailboxes then it seemed to whack the usage numbers by a factor of two (I can't remember which way) on the mailboxes where I had already done a test run of quota -f user.USER. I saw things like that more than once and I never figured out what exactly has triggered it and which versions of cyrus were affected. However, I found a general rule which seems important at least it was so when I last had a problem with quotas with 2.3.7: Always make sure that your metadata is clean before using quota -f. If in doubt, run reconstruct first. This seems to also be the case after some upgrades. So for me I'm now always doing a reconstruct before a quota -f. This can takes dozens of hours on large systems but better than having broken quotas for such a long period. Simon et all, Our site had a huge failure (we lost the config directory /var/imap) this weekend. We are now back running with a recovered mailboxes.db en *.sub files for our users (we didn't use reconstruct as that would take to long, 800Gigs of mail). The only thing still lacking is correct quotas. I set the quota for each mailbox to 'none' (to get everything working). Now I want to add a correct quota number. However I can set it with 'sq user.login x'. But requesting the quota gives me: tarzan lq user.rgevaert STORAGE 0/200 (0%) I am sure to have several megabytes. I looks like I have to run the quota program. In my case running quota didn't help until I reconstructed the mailbox. And I never tried to run quota -f with a mailbox-prefix. And then, I'm running 2.3.7 while you run a much older version which could also make a difference. I recommend to run reconstruct first and then quota -f. Simon Before doing it on the full system I would like to run it for my own mailbox. But: Running quota with both the -f option and mailbox-prefix arguments is not recommended. I'm running: name : Cyrus IMAPD version: v2.1.18 2005/02/14 06:45:19 Do you have any ideas what the consequences would be if I ran quota -f user.login on the running system? Thanks in advance, -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office Groep SystemenSystems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
On Mon, 11 Dec 2006, Nik Conwell wrote: I'm using the UW mailutil to transfer mailboxes from UW to Cyrus (2.3.7). It uses APPEND, specifically multiappend (single APPEND with multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Do people just tweak their kernels to have some insane number of FDs available in order to compensate for this? Or, do people not use mailutil and instead use something that issues multiple append commands rather than a single append with multiple e-mails? We run with a much, much larger number of file descriptors here. I've increased the system limit to around 200k (/proc/sys/fs/file-max on linux). This is for the day-to-day running of Cyrus, so I don't know if you would need a higher limit for running mailutil (but I doubt it). In practice, each of my backends has only used a maximum of around 12k file descriptors, but I'd hate to run out! :) Andy 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
--On 11 December 2006 10:07:46 AM -0500 Nik Conwell [EMAIL PROTECTED] wrote: | Or, do people not use mailutil and instead use something that issues | multiple append commands rather than a single append with multiple e- | mails? For our transition, we used a modified version of mailutil that (among other things) performs one append per message. | Do people just tweak their kernels to have some insane number of FDs | available in order to compensate for this? We did that, too. -Benn- 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
On Dec 11, 2006, at 12:29 PM, Andrew Morgan wrote: On Mon, 11 Dec 2006, Nik Conwell wrote: I'm using the UW mailutil to transfer mailboxes from UW to Cyrus (2.3.7). It uses APPEND, specifically multiappend (single APPEND with multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Do people just tweak their kernels to have some insane number of FDs available in order to compensate for this? Or, do people not use mailutil and instead use something that issues multiple append commands rather than a single append with multiple e-mails? We run with a much, much larger number of file descriptors here. I've increased the system limit to around 200k (/proc/sys/fs/file- max on linux). This is for the day-to-day running of Cyrus, so I don't know if you would need a higher limit for running mailutil (but I doubt it). In practice, each of my backends has only used a maximum of around 12k file descriptors, but I'd hate to run out! :) That's for the entire system though, right? I'm running into a 1024 limit per process, namely the cyrus imap server process has all the appended stage files open. Am I missing something fundamental here? (I probably am because I would have figured people would have run into this issue already...) BTW - my /proc/sys/fs/file-max has 406572. 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
Nik Conwell wrote: multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Excellent troubleshooting. I'm getting worried that I have a problem and don't know it. Did you get useful error messages (that we can search for, too)? The man page for cyrus.conf suggests that the default is 256, but that the integer value is optional. So if maxfds does not appear in cyrus.conf at all, is the default 256, or is it unlimited (up to ulimit)? Looks like the former to me. Ick. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Probably. -- Rich Graves [EMAIL PROTECTED] Sr UNIX and Security Administrator Ofc 507-646-7079 Cell 952-292-6529 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
On Mon, 11 Dec 2006, Nik Conwell wrote: On Dec 11, 2006, at 12:29 PM, Andrew Morgan wrote: On Mon, 11 Dec 2006, Nik Conwell wrote: I'm using the UW mailutil to transfer mailboxes from UW to Cyrus (2.3.7). It uses APPEND, specifically multiappend (single APPEND with multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Do people just tweak their kernels to have some insane number of FDs available in order to compensate for this? Or, do people not use mailutil and instead use something that issues multiple append commands rather than a single append with multiple e-mails? We run with a much, much larger number of file descriptors here. I've increased the system limit to around 200k (/proc/sys/fs/file-max on linux). This is for the day-to-day running of Cyrus, so I don't know if you would need a higher limit for running mailutil (but I doubt it). In practice, each of my backends has only used a maximum of around 12k file descriptors, but I'd hate to run out! :) That's for the entire system though, right? I'm running into a 1024 limit per process, namely the cyrus imap server process has all the appended stage files open. Am I missing something fundamental here? (I probably am because I would have figured people would have run into this issue already...) BTW - my /proc/sys/fs/file-max has 406572. Ah, then you just need to up the ulimits in your cyrus init script. Something like: # Crank up the limits ulimit -n 209702 ulimit -u 2048 ulimit -c 102400 Andy 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: When is it safe to adjust berkeley_cachesize?
On Sun, 2006-12-10 at 07:32 -0600, Gary Mills wrote: On Sat, Dec 09, 2006 at 10:12:36PM -0800, Ross Boylan wrote: I've returned to investigating why populating Cyrus 2.2 with UW's mailutil is rather slow (20 or 30 messages/second). One advice I've seen is to tweak berkeley_cachesize. When is it safe to do so? Only when creating a new database? Only when cyrus is shutdown? On the fly? Last time I did this, I just ran a bunch of them in parallel. That allowed me to adjust the load placed on the IMAP server. That sounds worth a try. I've been assuming the hold up is disk access, or maybe db access, in which case it didn't seem going parallel would help. But that's just an assumption; if it worked for you maybe it will work for me. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
On Dec 11, 2006, at 1:02 PM, Rich Graves wrote: Nik Conwell wrote: multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Excellent troubleshooting. I'm getting worried that I have a problem and don't know it. Did you get useful error messages (that we can search for, too)? The server logs: IOERROR: creating message file /var/spool/imap/stage./ 828-1165849099-1008: File exists The file is named pid-timestamp-stage_sequence_number The File exists error is bogus. With strace you see the real error: open(/var/spool/imap/stage./828-1165849099-1008, O_RDWR|O_CREAT| O_TRUNC, 0666) = -1 EMFILE (Too many open files) and then the code goes on try a mkdir so it loses the errno: mkdir(/var/spool/imap/stage./, 0755) = -1 EEXIST (File exists) following through the rest of the trace you see everything being unwound: close(1023) = 0 munmap(0xb652b000, 4096)= 0 unlink(/var/spool/imap/stage./828-1165849099-1007) = 0 close(1022) = 0 munmap(0xb652c000, 4096)= 0 unlink(/var/spool/imap/stage./828-1165849099-1006) = 0 close(1021) = 0 [...] The man page for cyrus.conf suggests that the default is 256, but that the integer value is optional. So if maxfds does not appear in cyrus.conf at all, is the default 256, or is it unlimited (up to ulimit)? Looks like the former to me. Ick. Looks like the former to me as well since it was crapping out at 240 stage files (a bunch of files already open when it started). 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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
On Dec 11, 2006, at 1:27 PM, Andrew Morgan wrote: On Mon, 11 Dec 2006, Nik Conwell wrote: On Dec 11, 2006, at 12:29 PM, Andrew Morgan wrote: On Mon, 11 Dec 2006, Nik Conwell wrote: I'm using the UW mailutil to transfer mailboxes from UW to Cyrus (2.3.7). It uses APPEND, specifically multiappend (single APPEND with multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated / etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Do people just tweak their kernels to have some insane number of FDs available in order to compensate for this? Or, do people not use mailutil and instead use something that issues multiple append commands rather than a single append with multiple e-mails? We run with a much, much larger number of file descriptors here. I've increased the system limit to around 200k (/proc/sys/fs/file- max on linux). This is for the day-to-day running of Cyrus, so I don't know if you would need a higher limit for running mailutil (but I doubt it). In practice, each of my backends has only used a maximum of around 12k file descriptors, but I'd hate to run out! :) That's for the entire system though, right? I'm running into a 1024 limit per process, namely the cyrus imap server process has all the appended stage files open. Am I missing something fundamental here? (I probably am because I would have figured people would have run into this issue already...) BTW - my /proc/sys/fs/file-max has 406572. Ah, then you just need to up the ulimits in your cyrus init script. Something like: # Crank up the limits ulimit -n 209702 ulimit -u 2048 ulimit -c 102400 That did the trick. Thanks a lot. -nik 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
cyrus replication question
while trying to setup cyrus replication
i am getting the following error
on the secondary server ( the one that is getting a copy of everything)
Dec 9 12:35:34 mars master[7701]: about to exec
/usr/local/cyrus/bin/sync_server
Dec 9 12:35:34 mars syncserver[7701]: executed
Dec 9 12:35:34 mars syncserver[7701]: accepted connection
Dec 9 12:35:34 mars syncserver[7701]: cmdloop(): startup
Dec 9 12:35:34 mars master[7694]: process 7701 exited, status 75
Dec 9 12:35:34 mars master[7694]: service syncserver pid 7701 in BUSY
state: terminated abnormally
here are the settings from both imapd.conf and cyrus.conf
for both master and backup server.
master server
(from where everything is being copied)
cyrus.conf
under START section:
syncclientcmd=/usr/local/cyrus/bin/sync_client -r -t
imapd.conf
#replication configurations
sync_host: server.mydomain.com
sync_authname: cyrus
sync_passwd: password
sync_machineid: 1
sync_log: 1
secondary
(to where everything is bein copied)
cyrus.conf
SERVICES {
syncservercmd=sync_server listen=csync
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: BUG? File descriptor use in cmd_append (for MULTIAPPEND) results in many open files
Hi, have you considered using imapsync instead? Nik Conwell wrote: I'm using the UW mailutil to transfer mailboxes from UW to Cyrus (2.3.7). It uses APPEND, specifically multiappend (single APPEND with multiple messages being appended). Cyrus-imapd handles this multiappend by creating stage files for each appended message and leaving the file descriptor open. The problem is that after 240 messages, we run out of file descriptors and so an open() of the next stage file fails with EMFILE. I updated /etc/cyrus.conf to make the max fds be 1024 (AFAICT kernel MAX) which helped somewhat but not for larger mailboxes with 1008 messages. Shouldn't the multiappend/append be closing the FD for each stage file and then reopening it later as it needs it? Do people just tweak their kernels to have some insane number of FDs available in order to compensate for this? Or, do people not use mailutil and instead use something that issues multiple append commands rather than a single append with multiple e-mails? -nik 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 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: cyrus replication question
another question :
do i need to create mailboxes
on the replica server or will they be created by the replication
process ?
while trying to setup cyrus replication
i am getting the following error
on the secondary server ( the one that is getting a copy of everything)
Dec 9 12:35:34 mars master[7701]: about to exec
/usr/local/cyrus/bin/sync_server
Dec 9 12:35:34 mars syncserver[7701]: executed
Dec 9 12:35:34 mars syncserver[7701]: accepted connection
Dec 9 12:35:34 mars syncserver[7701]: cmdloop(): startup
Dec 9 12:35:34 mars master[7694]: process 7701 exited, status 75
Dec 9 12:35:34 mars master[7694]: service syncserver pid 7701 in BUSY
state: terminated abnormally
here are the settings from both imapd.conf and cyrus.conf
for both master and backup server.
master server
(from where everything is being copied)
cyrus.conf
under START section:
syncclientcmd=/usr/local/cyrus/bin/sync_client -r -t
imapd.conf
#replication configurations
sync_host: server.mydomain.com
sync_authname: cyrus
sync_passwd: password
sync_machineid: 1
sync_log: 1
secondary
(to where everything is bein copied)
cyrus.conf
SERVICES {
syncservercmd=sync_server listen=csync
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
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: cyrus replication question
i started looking around
for one i found that for whatever reason
both sync and some other default process was using 2005/tcp port
(in /etc/services )
after taking care of that
i kicked off on sync_client on master server
(after logging in as cyrus)
on master server i get
can not connect to server 'replica.mydomain.com trying in 15 seconds.
and in /var/log/messages the following comes up
(still on master server)
Dec 11 16:09:56 master_server sync_client[93038]: TLS client engine:
cannot load CA data
Dec 11 16:09:56 master_server sync_client[93038]: Doing a peer verify
Dec 11 16:09:56 master_server sync_client[93038]: verify error:num=18:self
signed certificate
Dec 11 16:09:56 master_server sync_client[93038]: starttls: TLSv1 with
cipher AES256-SHA (256/256 bits new) no authentication
Dec 11 16:09:57 master_server sync_client[93038]: No worthy mechs found
Dec 11 16:09:57 master_server sync_client[93038]: couldn't authenticate to
backend server: no mechanism available
-
/var/log/messeges on replica server
is not saying anything at this point
but /var/log/debug.log has the following :
Dec 11 15:56:33 replica_server syncserver[92364]: accepted connection
Dec 11 15:56:33 replica_server syncserver[92364]: cmdloop(): startup
Dec 11 15:56:33 replica_server syncserver[92364]: mystore: starting txn
2147483668
Dec 11 15:56:33 replica_server syncserver[92364]: mystore: committing txn
2147483668
Dec 11 15:56:49 replica_server syncserver[92364]: accepted connection
Dec 11 15:56:49 replica_server syncserver[92364]: cmdloop(): startup
Dec 11 15:56:49 replica_server syncserver[92364]: mydelete: starting txn
2147483669
Dec 11 15:56:49 replica_server syncserver[92364]: mydelete: committing txn
2147483669
Dec 11 15:56:49 replica_server syncserver[92364]: mystore: starting txn
2147483670
Dec 11 15:56:49 replica_server syncserver[92364]: mystore: committing txn
2147483670
while trying to setup cyrus replication
i am getting the following error
on the secondary server ( the one that is getting a copy of everything)
Dec 9 12:35:34 mars master[7701]: about to exec
/usr/local/cyrus/bin/sync_server
Dec 9 12:35:34 mars syncserver[7701]: executed
Dec 9 12:35:34 mars syncserver[7701]: accepted connection
Dec 9 12:35:34 mars syncserver[7701]: cmdloop(): startup
Dec 9 12:35:34 mars master[7694]: process 7701 exited, status 75
Dec 9 12:35:34 mars master[7694]: service syncserver pid 7701 in BUSY
state: terminated abnormally
here are the settings from both imapd.conf and cyrus.conf
for both master and backup server.
master server
(from where everything is being copied)
cyrus.conf
under START section:
syncclientcmd=/usr/local/cyrus/bin/sync_client -r -t
imapd.conf
#replication configurations
sync_host: server.mydomain.com
sync_authname: cyrus
sync_passwd: password
sync_machineid: 1
sync_log: 1
secondary
(to where everything is bein copied)
cyrus.conf
SERVICES {
syncservercmd=sync_server listen=csync
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
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: some notes on upgrading from 2.1.15 to 2.2.12
Simon Matter wrote: In my case running quota didn't help until I reconstructed the mailbox. And I never tried to run quota -f with a mailbox-prefix. And then, I'm running 2.3.7 while you run a much older version which could also make a difference. I recommend to run reconstruct first and then quota -f. Simon Before doing it on the full system I would like to run it for my own mailbox. But: Running quota with both the -f option and mailbox-prefix arguments is not recommended. I took the chance, and it doesn't seem to have any consequences. Several users have folders without a cyrus.header file*. I have run a reconstruct on those folders only and then I was able to run quota -f user.login. I also had to reset permissions on those folders too. * I have no idea how those folders got there. It looks like they come from a previous migration. Rudy PS Loosing /var/imap over the weekend is not funny :) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur Direction ICT, Infrastructure dept. Groep Systemen Systems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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
virtdomains + global admin + sql backend for sasl2 ... how?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, I'm obviously missing something, cause its not working ... I setup defaultdomain in imapd.conf to point to the domain, so now when I try to login, it shows: plaintext cyrus SASL(-13): user not found: checkpass failed and, in my sql backend, I have a user '[EMAIL PROTECTED]', such that: sasl_pwcheck_method: auxprop auxprop_plugin: sql sasl_sql_engine: mysql sasl_sql_hostnames: localhost sasl_sql_database: dtc sasl_sql_user: dtcdaemons sasl_sql_select: SELECT passwd FROM pop_access WHERE fullemail = '[EMAIL PROTECTED]' sasl_sql_verbose: yes SELECT passwd FROM pop_access WHERE fullemail = '[EMAIL PROTECTED]'; ++ | passwd | ++ | cyrus | ++ 1 row in set (0.00 sec) But I still get an auth-failed ... And the sasl_sql_verbose setting doesn't appear to do anything, since I'm getting nadda in my log files that I can find :( So, what's the magic I'm missing here to get it to work? :( Thanks ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFfhnO4QvfyHIvDvMRAjDVAKC6srPJdiesry4th3UNIngN79oAHQCghrNJ 7Wan2uCtEEZWErgB0A2138U= =mU5K -END PGP SIGNATURE- 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: virtdomains + global admin + sql backend for sasl2 ... how?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Monday, December 11, 2006 22:54:06 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, I'm obviously missing something, cause its not working ... I setup defaultdomain in imapd.conf to point to the domain, so now when I try to login, it shows: plaintext cyrus SASL(-13): user not found: checkpass failed and, in my sql backend, I have a user '[EMAIL PROTECTED]', such that: sasl_pwcheck_method: auxprop auxprop_plugin: sql sasl_sql_engine: mysql sasl_sql_hostnames: localhost sasl_sql_database: dtc sasl_sql_user: dtcdaemons sasl_sql_select: SELECT passwd FROM pop_access WHERE fullemail = '[EMAIL PROTECTED]' sasl_sql_verbose: yes SELECT passwd FROM pop_access WHERE fullemail = '[EMAIL PROTECTED]'; ++ | passwd | ++ | cyrus | ++ 1 row in set (0.00 sec) But I still get an auth-failed ... And the sasl_sql_verbose setting doesn't appear to do anything, since I'm getting nadda in my log files that I can find :( So, what's the magic I'm missing here to get it to work? :( 'k, think I just figured it out ... had virtdomain set to 1 .. changing it to userid seems to fix it .. will do more testing, but Ithink I have it ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFfjSU4QvfyHIvDvMRAhSIAJwPDS8LP+xNr6OBG6o7hTQCHom7XQCgh8R+ ozMbp3TxeAD2bwgZjXoX0Kw= =rPPT -END PGP SIGNATURE- 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: DB4 downgrade
Simon Matter wrote: I finally got a window of scheduled downtime to test this, and I'm having problems. Here's what I did: # /etc/init.d/cyrus-imapd stop # db_checkpoint -v -1 -h /var/lib/imap/db # db_recover -v -h /var/lib/imap/db # rm db/* # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/deliver.db berkeley /var/lib/imap/deliver.db.skip skiplist # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/tls_sessions.db berkeley /var/lib/imap/tls_sessions.db.skip skiplist # mv deliver.db.skip deliver.db ; mv tls_sessions.db.skip tls_sessions.db # chown cyrus:mail tls_sessions.db deliver.db # /etc/init.d/cyrus-imapd start At this point, the log explodes with messages along the lines of: Dec 11 06:11:53 ajax imaps[1394]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imaps pid 1394 in READY state: terminated abnormally Dec 11 06:11:53 ajax master[32203]: service lmtpunix pid 1397 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1395]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1395]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imap pid 1395 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1399]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1399]: DBERROR: critical database situation Dec 11 06:11:53 ajax imaps[1400]: DBERROR A : db4 Dec 11 06:11:53 ajax imaps[1400]: DBERROR: critical database situation Any ideas on why this is going on? I did notice that /var/lib/imap/rpm/db.cfg.cache has entries along the lines of: CONFIG_DB_DUPLICATE=berkeley CONFIG_DB_MBOX=skiplist CONFIG_DB_SEEN=skiplist CONFIG_DB_SUBS=flat CONFIG_DB_TLS=berkeley CONFIG_DB_ANNOTATION=skiplist CONFIG_DB_SIEVE=2.2.3 Is there someplace I need to tell imapd that deliver and tls_sessions are now skiplist? I don't see anything in /etc/imapd.conf and /etc/cyrus.conf. Something is really broken here... First shutdown using 'service cyrus-imapd stop', then put this in /etc/imapd.conf: duplicate_db: skiplist tlscache_db: skiplist Now try to start it up using 'service cyrus-imapd start'. Unfortunately I think the cyrus-imapd package shipped with FC4 has some bugs in the init scripts. I recommend you use my rpms, which are newer and have less bugs. RedHat ships old versions of my rpms which don't include the latest bug fixes. Find the source rpm here: http://www.invoca.ch/pub/packages/cyrus-imapd/ I tried what you suggested regarding just the /etc/imapd.conf changes, but without using your RPMs. There was no change: DBERROR messages everywhere until the imapd service was stopped, etc. I will try using your RPMs during the next period of scheduled maintenance, later this week. Thanks again. 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
cyrus umask
Hello, i have installed cyrus 2.2.12 on gentoo. My problem is that the umask didn´t work like it should when moving messages in thunderbird from one folder to another. I use amavis on my system and want to set moved messages with following permissions: 650 It worked when cyrus is delivering the mail through sieve to the folders, but when i move a message in thunderbird i get following permissions set in the folder for example SPAM. The permission is then 600 ? I do not understand why ? What process of cyrus is moving messages when they where moved with an MUA ? My umask in imapd.conf is set to: umask: 027 User and group of the imap spool Folders are: cyrus:mail group: mail::12:mail,cyrus,postfix,amavis Are there any security issues not to set the umask to 027 ? Regards, Peter 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
How to remove a users sieve sieve script?
Hello info-cyrus readers, how can I remove a users sieve script? Is it possible to just delete his files under /var/imap/sieve/x/y ? Kind regards, Timo 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: timeouts when connecting to imap server
Hi, isn't there anyone who can say something about my finding? Is it wrong and/or should I take it to cyrus-devel? Kind regards, Timo 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
