�������ѡ���������������Ҫ��Ϣ
http://www.sh-esun.com/zhufu.htm
Autocreate bug fixed (was Re: DB Errors [SOLVED])
Hi Daniel, Ok I found the problem. It is really autocreate's fault. I bet you use a 2.1.x version of cyrus, because in cyrus 2.2.12 it is already fixed. Now it is fixed in 2.1.18 too (patch version 0.9.4). Get it from http://email.uoa.gr/download/cyrus/cyrus-imapd-2.1.18/ Regards, Christos Daniel Hazelbaker said: Okay, after knocking down our mail server for an hour to track this down I have a solution. I do not remember where, but somewhere when I was setting this up years ago I read that the method for delivering from postfix-procmail-spamassassin-cyrus was to have postfix deliver to procmail, and procmail instruct spamassassin to do its thing. Then to use the cyrus deliver program with -a $LOGNAME -m user.$LOGNAME to deliver the message. Well what was happening is this: Breakpoint 1, verify_user (user=0x0, domain=0x0, mailbox=0x100f8189 user.kristina, quotacheck=0, authstate=0x0) at lmtpd.c:554 This combination (user = null and mailbox != null and mailbox does not exist) would cause verify_user to pass userinbox (== null) to autocreate_inbox, which would strcmp without any error checking and segfault. The solution seems to be to change the deliver line to just -a $LOGNAME $LOGNAME and it seems to work properly for everything. Daniel Hazelbaker On Apr 26, 2005, at 4:45 PM, Daniel Hazelbaker wrote: I don't believe it is no symbols, I believe it is smashing the stack somehow (those are the only two entries in the stack). Can't imagine how strcmp is smashing the stack but I suppose anything is possible. I'll try to attach, but I thought lmtpd forked a child process in the same way httpd does, maybe not though. --- 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 -- Did you visit http://email.uoa.gr? --- 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: DB Errors [SOLVED]
Hi again Daniel. I just saw that you use cyrus-imapd-2.2.10, packaged in YDL 4.0. And this bug has been fixed in autocreate patch for cyrus-2.2.10 for quite sometime. The autocreate patch for cyrus-imapd-2.2.10 (patch versions 0.9.0 0.9.1) checks userinbox variable and does not sefault. snip from autocreate_inbox() in lmtpd.c patch 0.9.0 + +if(rcpt_userid == NULL) + return IMAP_MAILBOX_NONEXISTENT; + /snip So what I can think of are the following : 1. Your distro did not include this fix in the distributed cyrus package. 2. Segfault is caused by something else. Please check your sources and let me know if I can do something to fix it. Regards, Christos Daniel Hazelbaker said: Okay, after knocking down our mail server for an hour to track this down I have a solution. I do not remember where, but somewhere when I was setting this up years ago I read that the method for delivering from postfix-procmail-spamassassin-cyrus was to have postfix deliver to procmail, and procmail instruct spamassassin to do its thing. Then to use the cyrus deliver program with -a $LOGNAME -m user.$LOGNAME to deliver the message. Well what was happening is this: Breakpoint 1, verify_user (user=0x0, domain=0x0, mailbox=0x100f8189 user.kristina, quotacheck=0, authstate=0x0) at lmtpd.c:554 This combination (user = null and mailbox != null and mailbox does not exist) would cause verify_user to pass userinbox (== null) to autocreate_inbox, which would strcmp without any error checking and segfault. The solution seems to be to change the deliver line to just -a $LOGNAME $LOGNAME and it seems to work properly for everything. Daniel Hazelbaker On Apr 26, 2005, at 4:45 PM, Daniel Hazelbaker wrote: I don't believe it is no symbols, I believe it is smashing the stack somehow (those are the only two entries in the stack). Can't imagine how strcmp is smashing the stack but I suppose anything is possible. I'll try to attach, but I thought lmtpd forked a child process in the same way httpd does, maybe not though. --- 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 -- Did you visit http://email.uoa.gr? --- 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
Cyrus IMAP migration
I was wondering if anybody here has any experience migrating a Cyrus IMAP server from one platform to another. My current IMAP server is an Alpha EV56; the new server is an Opteron 140. Both run FreeBSD 6. Both are little-endian I32LP64 machines. There is one very important difference, though: time_t is 32 bits wide on the Alpha and 64 bits wide on the Opteron. This means binary files which contain time_ts will not be readable on the Opteron. So my question is: does Cyrus store time_ts in binary files, and if so, is there any way I can locate those files and convert them to the proper format when I copy them over? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] --- 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
DBERROR: opening /imap/conf/tls_sessions.db
The other day, we had a couple of complaints that SSL had stopped working with Cyrus IMAP. This was followed by complaints that e-mail sending with SMTP was not working. Reading e-mail with IMAP or POP was not affected. When I checked, all of the lmtpd processes were blocked waiting for a mutex lock. I tried to run db_stat, but it also blocked the same way. A stack trace on one of the lmtpd processes showed that it was attempting to check the duplicate delivery database. Stopping and starting master resolved the problem. The first error messages in the messages log were these four: Apr 29 14:48:55 electra imapd[9057]: [ID 729713 local6.error] DBERROR: opening /imap/conf/tls_sessions.db: Invalid argument Apr 29 14:48:55 electra imapd[5401]: [ID 729713 local6.error] DBERROR: opening /imap/conf/tls_sessions.db: Invalid argument Apr 29 14:48:55 electra imapd[5401]: [ID 729713 local6.error] DBERROR: opening /imap/conf/tls_sessions.db: cyrusdb error Apr 29 14:48:55 electra imapd[9057]: [ID 729713 local6.error] DBERROR: opening /imap/conf/tls_sessions.db: cyrusdb error These were followed a few minutes later by many like these that only ended with the restart: Apr 29 14:50:48 electra sm-mta[4265]: [ID 801593 mail.crit] j3TJolFM004224: SYSERR(root): Could not connect to socket /var/run/imap/lmtp: Connection refused by localhost Apr 29 14:50:48 electra sm-mta[4266]: [ID 801593 mail.crit] j3TJoZHn004191: SYSERR(root): Could not connect to socket /var/run/imap/lmtp: Connection refused by localhost The problem with lmtpd seems to have been a deadlock on the duplicate delivery database. Could it have been caused by the previous problem with the TLS sessions database? How do I prevent the initial problem? We are using skiplist for the mboxlist and seen databases, but db-3.1.17 for the duplicate delivery and TLS sessions databases. The Cyrus version is 2.1.14, running under Solaris 9. Cyrus had been running smoothly for some time before this problem occured. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- --- 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
