Cyrus-IMAP Server Dead -- Any suggestions???

[Webb, Paul]

Hi all,

If you haven't figured it out yet, I seem to have a talent for killing 
Kolab servers....  I think I'm on my 5th install of Kolab on various 
platforms and hardware! Thankfully most haven't had any real data on 
them yet! :-)

Server OS: Ubuntu v6.10 "Edgy Eft", all updates applied.

I finally got a Kolab install completed without incident by following 
the Ubuntu HOWTO wiki -- no fatal errors, no reasons for concern. I've 
posted my kolab-build.log file for you all to look at, just in case 
there is any question... Horde didn't work, but as I understand it Horde 
is extremely experimental at this point, so I didn't bother trying to 
make it work.

    http://tinyurl.com/36mpee

In any case, I set up an administrative user (me!) and then designated 
them the administrative email account. I set all of my service settings 
without incident. I then added an additional domain, set up an admin 
user, and assigned them. I did this about 4 times for a total of about 5 
domains. No incidents.

Tested connectivity to the server using both Mozilla Thunderbird and 
Kontact by using the Kontact wiki and HowTos available. No incidents.

All looked good, so I started the process of copying a few IMAP accounts 
from my exchange server to my kolab server. Thankfully I didn't *move*, 
I just *copied* the mail.

I'll admit, I was hammering the server pretty hard with migration 
requests. I had three migrations running in three console windows on the 
server. Probably not the smartest idea, but I had to test what would 
happen in real life, right? ;-)

In any case, at 12:10am this morning, my cyrus-imap server dropped 
offline. All of the migrations failed (obviously). I'm not sure whether 
my bombarding the server with migrations was the cause, or whether the 
cause is unrelated.

A restart of the service daemons does not fix it. A reboot doesn't fix 
it, either.

After looking at the logs, I find the following error each time I try to 
start the imap daemon:*

*From /kolab/var/imapd/log/master.log

    /Apr 11 19:16:02 postman <notice> master[11977]: process started
    Apr 11 19:16:02 postman <debug> master[11980]: about to exec
    /kolab/bin/ctl_cyrusdb
    Apr 11 19:16:11 postman <error> master[11985]: setrlimit: Unable to
    set file descriptors limit to -1: (1) Operation not permitted
    Apr 11 19:16:11 postman <error> master[11985]: retrying with 1024
    (current max)
    Apr 11 19:16:11 postman <notice> master[11985]: process started
    Apr 11 19:16:11 postman <debug> master[11986]: about to exec
    /kolab/bin/ctl_cyrusdb
    Apr 11 19:21:24 postman <error> master[14933]: setrlimit: Unable to
    set file descriptors limit to -1: (1) Operation not permitted
    Apr 11 19:21:24 postman <error> master[14933]: retrying with 1024
    (current max)
    Apr 11 19:21:24 postman <notice> master[14933]: process started
    Apr 11 19:21:24 postman <debug> master[14971]: about to exec
    /kolab/bin/ctl_cyrusdb
    /

As you can see, the error repeats itself. There's nothing more listed.

In case you're wondering, that directory looks like this:

    /root at postman:/kolab/var/imapd/log# ls -l
    total 3592
    -rw-rw-rw- 1 kolab-r kolab-r  226035 2007-04-11 19:21 cyr_db.log
    -rw-r--r-- 1 kolab-r kolab-r       0 2007-04-11 00:03 imapd.log
    -rw-r--r-- 1 kolab-r kolab-r 3228412 2007-04-11 00:04 imapd.log.0
    -rw-r--r-- 1 root    root     197045 2007-04-11 19:21 master.log
    -rw-r--r-- 1 kolab-r kolab-r     771 2007-04-05 14:41 sieve.log/

I Googled this and couldn't find any definitive solution. It looks like 
another gentleman had this problem with Kolab, but he opted to wipe his 
install clean and reinstall. I'd prefer not to take that route if possible!

If the solution ends up being "delete your cyrus-imap databases using 
this command and restart", that's cool. Again, I have all of my data on 
my production (Exchange) email server. I'd prefer to get kolab up and 
running to decommission the Exchange server, but I'm not at a critical 
point at the moment.

TIA!
--
Paul Webb
WebbEnabled Solutions, LLC
http://www.webbenabled.com
pwebb at webbenabled.com