Re: Problem w/ 2.2.4 and unixhierarchysep: yes
> Simon Matter wrote: >>>Simon Matter wrote: >>> >>> >On Sun, 23 May 2004, Simon Matter wrote: > > > >>I have just finished rebuilding my 2.2.4 rpms and I've got the same >>problem on my own server where I tested the build. I was able to >> access >>some folders but some others didn't work. > >Was there anything consistant about these folders (specifically, did >they >have quotas associated with them)? > >Sadly, the backtrace you provided doesn't appear to be valid (why does >strcpy() call strcpy() and then call shut_down()? Hm, I think this one is correct. Sorry for the noise. >>> >>>Hmm, the backtrace doesn't seem to show anything obvious, but your >>>strace looks like is crashes right after a close(). I've been running >>>this code since I wrote it (January?) without any problems on my RH9/XFS >>> box. I'm wondering if this is some weird filesystem issue. What >>>filesystem(s) are you using? >> >> >> The backtrace is from RedHat 7.2 running ext3. Nothing special here. >> Switching back to 2.2.3 made it work again and I also don't see any >> corruption. > > Are the backtraces and straces consistent in their content? I didn't create them at the same time. But I straced again and again and it always crashes at the same place. It's always after the close() after renaming the quota file. Simon > > >>> (gdb) bt #0 0x080a0947 in hash_enumerate (table=0x8147de0, func=0x809d3c0 , rock=0xbfff9fe0) at hash.c:313 #1 0x0809d449 in commit_txn (db=0x8147dd8, tid=0x8147de0) at cyrusdb_quotalegacy.c:715 #2 0x0808bea5 in quota_commit (tid=0xbfffa07c) at quota_db.c:120 #3 0x0807215b in mailbox_expunge (mailbox=0x812dc00, iscurrentdir=1, decideproc=0, deciderock=0x0) at mailbox.c:1863 #4 0x08057dd4 in cmd_expunge (tag=0x81489a0 "A003", sequence=0x0) at imapd.c:3612 #5 0x08050980 in cmdloop () at imapd.c:1026 #6 0x0804f920 in service_main (argc=1, argv=0x813d410, envp=0xbfffe99c) at imapd.c:677 #7 0x0804df29 in main (argc=1, argv=0xbfffe994, envp=0xbfffe99c) at service.c:557 #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, ubp_av=0xbfffe994, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbfffe98c) at ../sysdeps/generic/libc-start.c:129 --- 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 >>> >>> >>>-- >>>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 >> > > > -- > 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: Not seeing sub-folders when migrating/upgrading
On Sun, 2004-05-23 at 22:44, Andrew Davis wrote: > Thank you so much. That's the information I was looking for. Does this > mean I can copy the mailboxes.db and the mailbox content and expect to > not see this problem? > I don't think that would work, especially if there's a difference in Cyrus versions. What will work is to dump the mailboxes db on the old server to a flat file with 'ctl_mboxlist -d >mailboxes.list'. Then on the new server import that with 'ctl_mboxlist -u 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: Not seeing sub-folders when migrating/upgrading
No... they don't. I covered that in my post to the list. AD Patrick Welche wrote: On Sat, May 22, 2004 at 02:51:46PM -0700, Andrew Davis wrote: Hello? Can anyone help me with the problem listed below? In squirrelmail, if you go to "Folders", do your Personal and Work folders appear in the column above the "Subscribe" button? If they do, subscribe to them! Cheers, Patrick Andrew Davis wrote: I am migrating from an older cyrus-imapd/postfix/webcyradm/squirrelmail solution on RH 7.3 to a new one with new versions of each on Fedora Core 1. All is setup and working fine with the exception of one problem: On my old box I have a user called 'link0033'. For testing, I created this same user on my new box with the same password. On the old system, I tar'd up the user's directory, copied it to my new box, and untar'd it. I set the appropriate permissions, then logged in 'link0033' on my new box via Squirrelmail. The problem is I only see the Inbox, Drafts, Sent, and Trash folders. The good news is that each has mail in it as they should. The bad news is that on my old box, I had created sub-folders of Work and Personal. Each has mail in it on the old server. When I log in via Squirrelmail, I don't see these folders. However, at the command line I can see them, see they have the permissions, and see the content within them. For kicks, I used the cyradm program as another test with: cyradm --user link0001 --server localhost --auth plain Once in, I did an "lm" and I only see the Inbox, Drafts, Sent, and Trash folders. So I now have two different programs with the same results. This is pointing me at a cyrus issue. Interestingly, on my new server, I was able to move the Personal folder via the command line, go to Squirrelmail -> and create a new Personal folder, then delete it at the command line and move the original back. When I log back into Squirrelmail, I can see the Personal folder *and* the contents of it that were brought over from my old server. So, is there something I need to be passing as a flag to cyrus? Perhaps a build option I should have used? My new system has cyrus-imapd-2.2.4. My older system has 2.1.12. Did something change between versions that's to blame? Is there a patch or tool I can use? -- Andrew Davis North County Computers http://www.nccomp.com Email: [EMAIL PROTECTED] Local: 760-525-4689 Toll Free: 877-735-4689 http://www.nccomp.com";>North County Computers --- 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: Not seeing sub-folders when migrating/upgrading
Thank you so much. That's the information I was looking for. Does this mean I can copy the mailboxes.db and the mailbox content and expect to not see this problem? AD Jim Levie wrote: On Sat, 2004-05-22 at 16:51, Andrew Davis wrote: Hello? Can anyone help me with the problem listed below? Andrew Davis wrote: I am migrating from an older cyrus-imapd/postfix/webcyradm/squirrelmail solution on RH 7.3 to a new one with new versions of each on Fedora Core 1. All is setup and working fine with the exception of one problem: On my old box I have a user called 'link0033'. For testing, I created this same user on my new box with the same password. On the old system, I tar'd up the user's directory, copied it to my new box, and untar'd it. I set the appropriate permissions, then logged in 'link0033' on my new box via Squirrelmail. The problem is I only see the Inbox, Drafts, Sent, and Trash folders. The good news is that each has mail in it as they should. The bad news is that on my old box, I had created sub-folders of Work and Personal. Each has mail in it on the old server. When I log in via Squirrelmail, I don't see these folders. However, at the command line I can see them, see they have the permissions, and see the content within them. In the transfer of data from the old server you missed a step, namely the dumping of the mailboxes db on the old server and loading it on the new server. Without that DB on the new server Cyrus doesn't know about your other mail folders. It worked for Squirrel mail because when it opened your inbox it didn't see Drafts, Sent, & Trash and created them. Cyrus was smart enough to realize that the directories were already present and simply made their content available. You can fix your test account by noting what folders (and possible subfolders) are present by a directory listing of the link0033 Cyrus INBOX and then doing a 'cm user.link0033.folder'. When you've done that for all folders follow it with a 'reconstruct -r user.link0033'. Depending on the client and how it is set up you may need to subscribe to all of the folders again. -- Andrew Davis North County Computers http://www.nccomp.com Email: [EMAIL PROTECTED] Local: 760-525-4689 Toll Free: 877-735-4689 http://www.nccomp.com";>North County Computers --- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
Simon Matter wrote: Simon Matter wrote: On Sun, 23 May 2004, Simon Matter wrote: I have just finished rebuilding my 2.2.4 rpms and I've got the same problem on my own server where I tested the build. I was able to access some folders but some others didn't work. Was there anything consistant about these folders (specifically, did they have quotas associated with them)? Sadly, the backtrace you provided doesn't appear to be valid (why does strcpy() call strcpy() and then call shut_down()? Hm, I think this one is correct. Sorry for the noise. Hmm, the backtrace doesn't seem to show anything obvious, but your strace looks like is crashes right after a close(). I've been running this code since I wrote it (January?) without any problems on my RH9/XFS box. I'm wondering if this is some weird filesystem issue. What filesystem(s) are you using? The backtrace is from RedHat 7.2 running ext3. Nothing special here. Switching back to 2.2.3 made it work again and I also don't see any corruption. Are the backtraces and straces consistent in their content? (gdb) bt #0 0x080a0947 in hash_enumerate (table=0x8147de0, func=0x809d3c0 , rock=0xbfff9fe0) at hash.c:313 #1 0x0809d449 in commit_txn (db=0x8147dd8, tid=0x8147de0) at cyrusdb_quotalegacy.c:715 #2 0x0808bea5 in quota_commit (tid=0xbfffa07c) at quota_db.c:120 #3 0x0807215b in mailbox_expunge (mailbox=0x812dc00, iscurrentdir=1, decideproc=0, deciderock=0x0) at mailbox.c:1863 #4 0x08057dd4 in cmd_expunge (tag=0x81489a0 "A003", sequence=0x0) at imapd.c:3612 #5 0x08050980 in cmdloop () at imapd.c:1026 #6 0x0804f920 in service_main (argc=1, argv=0x813d410, envp=0xbfffe99c) at imapd.c:677 #7 0x0804df29 in main (argc=1, argv=0xbfffe994, envp=0xbfffe99c) at service.c:557 #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, ubp_av=0xbfffe994, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbfffe98c) at ../sysdeps/generic/libc-start.c:129 --- 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 -- 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 -- 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-imap cyrus-sasl postfix [SOLVED]
On Sat, 2004-05-22 at 00:02, Patrick Nelson wrote: > Not sure if anyone can help but here is my problem > -- > FC1 > cyrus-imap 2.2.3 > Postfix 2.1.1 > cyrus-sasl 2.1.15 > > I have followed everything in the sasl readme, but I can not get auth > plain to work. > > I think sasl is setup correctly because I can use: > > testsaslauthd -u -p > > and I get a 0: OK "Success." > > But when I try to manually use telnet localhost 25 and then try to > authenticate with AUTH PLAIN It keep coming back saying > it 535 Error: authentication failed > > I know the base64 gen script is producing the correct code (followed > sasl readme) is correct because I can use it on another system. > > My main.cf has the sasl entries: > > smtpd_sasl_auth_enable = yes > smtpd_sasl_security_options = noanonymous > smtpd_sasl_local_domain = > broken_sasl_auth_clients = yes > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > check_recipient_access hash:/etc/postfix/filter-domains > reject_unknown_sender_domain, > reject_unauth_destination > > here is the maillog entry: > > May 21 23:33:12 amks postfix/smtpd[6460]: connect from amks[127.0.0.1] > May 21 23:33:31 amks postfix/smtpd[6460]: warning: SASL authentication > failure: Password verification failed > May 21 23:33:31 amks postfix/smtpd[6460]: warning: amks[127.0.0.1]: SASL > plain authentication failed > May 21 23:33:38 amks postfix/smtpd[6460]: disconnect from > amks[127.0.0.1] > > /etc/sysconfig/saslauthd: > MECH=pam > FLAGS="-n 0-c" > > Anyone see or guess at what I'm doing wrong? I must have moved instead of copied my PAM smtp to pop config files. When I copied pop to smtp... All worked! --- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
Redhat 7.3 and EXT3 here too, also switching back to 2.2.3 fixed it. AJ Simon Matter wrote: >>On Sun, 23 May 2004, Simon Matter wrote: >> >> >>>I have just finished rebuilding my 2.2.4 rpms and I've got the same >>>problem on my own server where I tested the build. I was able to access >>>some folders but some others didn't work. >> >>Was there anything consistant about these folders (specifically, did they >>have quotas associated with them)? >> >>Sadly, the backtrace you provided doesn't appear to be valid (why does >>strcpy() call strcpy() and then call shut_down()? > > > Hm, I think this one is correct. Sorry for the noise. Hmm, the backtrace doesn't seem to show anything obvious, but your strace looks like is crashes right after a close(). I've been running this code since I wrote it (January?) without any problems on my RH9/XFS box. I'm wondering if this is some weird filesystem issue. What filesystem(s) are you using? --- 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: Not seeing sub-folders when migrating/upgrading
On Sat, 2004-05-22 at 16:51, Andrew Davis wrote: > Hello? Can anyone help me with the problem listed below? > > Andrew Davis wrote: > > I am migrating from an older cyrus-imapd/postfix/webcyradm/squirrelmail > > solution on RH 7.3 to a new one with new versions of each on Fedora Core > > 1. All is setup and working fine with the exception of one problem: > > > > On my old box I have a user called 'link0033'. For testing, I created > > this same user on my new box with the same password. On the old system, > > I tar'd up the user's directory, copied it to my new box, and untar'd > > it. I set the appropriate permissions, then logged in 'link0033' on my > > new box via Squirrelmail. The problem is I only see the Inbox, Drafts, > > Sent, and Trash folders. The good news is that each has mail in it as > > they should. The bad news is that on my old box, I had created > > sub-folders of Work and Personal. Each has mail in it on the old server. > > When I log in via Squirrelmail, I don't see these folders. However, at > > the command line I can see them, see they have the permissions, and see > > the content within them. > > In the transfer of data from the old server you missed a step, namely the dumping of the mailboxes db on the old server and loading it on the new server. Without that DB on the new server Cyrus doesn't know about your other mail folders. It worked for Squirrel mail because when it opened your inbox it didn't see Drafts, Sent, & Trash and created them. Cyrus was smart enough to realize that the directories were already present and simply made their content available. You can fix your test account by noting what folders (and possible subfolders) are present by a directory listing of the link0033 Cyrus INBOX and then doing a 'cm user.link0033.folder'. When you've done that for all folders follow it with a 'reconstruct -r user.link0033'. Depending on the client and how it is set up you may need to subscribe to all of the folders again. -- The instructions said to use Windows 98 or better, so I installed RedHat. --- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
> Simon Matter wrote: > >>>On Sun, 23 May 2004, Simon Matter wrote: >>> >>> I have just finished rebuilding my 2.2.4 rpms and I've got the same problem on my own server where I tested the build. I was able to access some folders but some others didn't work. >>> >>>Was there anything consistant about these folders (specifically, did >>> they >>>have quotas associated with them)? >>> >>>Sadly, the backtrace you provided doesn't appear to be valid (why does >>>strcpy() call strcpy() and then call shut_down()? >> >> >> Hm, I think this one is correct. Sorry for the noise. > > Hmm, the backtrace doesn't seem to show anything obvious, but your > strace looks like is crashes right after a close(). I've been running > this code since I wrote it (January?) without any problems on my RH9/XFS > box. I'm wondering if this is some weird filesystem issue. What > filesystem(s) are you using? It happens just before cyrus.cache.NEW and cyrus.index.NEW are renamed. Those .NEW files are then left behind by the dead process. Wthout having a deep knowledge I still feel it's not a filesystem issue here. Simon > > >> >> (gdb) bt >> #0 0x080a0947 in hash_enumerate (table=0x8147de0, func=0x809d3c0 >> , rock=0xbfff9fe0) at hash.c:313 >> #1 0x0809d449 in commit_txn (db=0x8147dd8, tid=0x8147de0) at >> cyrusdb_quotalegacy.c:715 >> #2 0x0808bea5 in quota_commit (tid=0xbfffa07c) at quota_db.c:120 >> #3 0x0807215b in mailbox_expunge (mailbox=0x812dc00, iscurrentdir=1, >> decideproc=0, deciderock=0x0) at mailbox.c:1863 >> #4 0x08057dd4 in cmd_expunge (tag=0x81489a0 "A003", sequence=0x0) at >> imapd.c:3612 >> #5 0x08050980 in cmdloop () at imapd.c:1026 >> #6 0x0804f920 in service_main (argc=1, argv=0x813d410, envp=0xbfffe99c) >> at imapd.c:677 >> #7 0x0804df29 in main (argc=1, argv=0xbfffe994, envp=0xbfffe99c) at >> service.c:557 >> #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, >> ubp_av=0xbfffe994, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, >> rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbfffe98c) at >> ../sysdeps/generic/libc-start.c:129 >> >> >> --- >> 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 >> > > > -- > 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
Debian packages for Cyrus 2.2
Hello Cyrus experts, does someone know the status of the Debian packages for the Cyrus 2.2 generation? The last thread I found, was in November 2003. I'd like to use the realm option. Thank you for your information. Best regards, Mario // // Mario Schubert, Munich, Germany // [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
Re: Problem w/ 2.2.4 and unixhierarchysep: yes
> Simon Matter wrote: > >>>On Sun, 23 May 2004, Simon Matter wrote: >>> >>> I have just finished rebuilding my 2.2.4 rpms and I've got the same problem on my own server where I tested the build. I was able to access some folders but some others didn't work. >>> >>>Was there anything consistant about these folders (specifically, did >>> they >>>have quotas associated with them)? >>> >>>Sadly, the backtrace you provided doesn't appear to be valid (why does >>>strcpy() call strcpy() and then call shut_down()? >> >> >> Hm, I think this one is correct. Sorry for the noise. > > Hmm, the backtrace doesn't seem to show anything obvious, but your > strace looks like is crashes right after a close(). I've been running > this code since I wrote it (January?) without any problems on my RH9/XFS > box. I'm wondering if this is some weird filesystem issue. What > filesystem(s) are you using? The backtrace is from RedHat 7.2 running ext3. Nothing special here. Switching back to 2.2.3 made it work again and I also don't see any corruption. Simon > > >> >> (gdb) bt >> #0 0x080a0947 in hash_enumerate (table=0x8147de0, func=0x809d3c0 >> , rock=0xbfff9fe0) at hash.c:313 >> #1 0x0809d449 in commit_txn (db=0x8147dd8, tid=0x8147de0) at >> cyrusdb_quotalegacy.c:715 >> #2 0x0808bea5 in quota_commit (tid=0xbfffa07c) at quota_db.c:120 >> #3 0x0807215b in mailbox_expunge (mailbox=0x812dc00, iscurrentdir=1, >> decideproc=0, deciderock=0x0) at mailbox.c:1863 >> #4 0x08057dd4 in cmd_expunge (tag=0x81489a0 "A003", sequence=0x0) at >> imapd.c:3612 >> #5 0x08050980 in cmdloop () at imapd.c:1026 >> #6 0x0804f920 in service_main (argc=1, argv=0x813d410, envp=0xbfffe99c) >> at imapd.c:677 >> #7 0x0804df29 in main (argc=1, argv=0xbfffe994, envp=0xbfffe99c) at >> service.c:557 >> #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, >> ubp_av=0xbfffe994, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, >> rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbfffe98c) at >> ../sysdeps/generic/libc-start.c:129 >> >> >> --- >> 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 >> > > > -- > 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: Problem w/ 2.2.4 and unixhierarchysep: yes
Simon Matter wrote: On Sun, 23 May 2004, Simon Matter wrote: I have just finished rebuilding my 2.2.4 rpms and I've got the same problem on my own server where I tested the build. I was able to access some folders but some others didn't work. Was there anything consistant about these folders (specifically, did they have quotas associated with them)? Sadly, the backtrace you provided doesn't appear to be valid (why does strcpy() call strcpy() and then call shut_down()? Hm, I think this one is correct. Sorry for the noise. Hmm, the backtrace doesn't seem to show anything obvious, but your strace looks like is crashes right after a close(). I've been running this code since I wrote it (January?) without any problems on my RH9/XFS box. I'm wondering if this is some weird filesystem issue. What filesystem(s) are you using? (gdb) bt #0 0x080a0947 in hash_enumerate (table=0x8147de0, func=0x809d3c0 , rock=0xbfff9fe0) at hash.c:313 #1 0x0809d449 in commit_txn (db=0x8147dd8, tid=0x8147de0) at cyrusdb_quotalegacy.c:715 #2 0x0808bea5 in quota_commit (tid=0xbfffa07c) at quota_db.c:120 #3 0x0807215b in mailbox_expunge (mailbox=0x812dc00, iscurrentdir=1, decideproc=0, deciderock=0x0) at mailbox.c:1863 #4 0x08057dd4 in cmd_expunge (tag=0x81489a0 "A003", sequence=0x0) at imapd.c:3612 #5 0x08050980 in cmdloop () at imapd.c:1026 #6 0x0804f920 in service_main (argc=1, argv=0x813d410, envp=0xbfffe99c) at imapd.c:677 #7 0x0804df29 in main (argc=1, argv=0xbfffe994, envp=0xbfffe99c) at service.c:557 #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, ubp_av=0xbfffe994, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbfffe98c) at ../sysdeps/generic/libc-start.c:129 --- 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 -- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
> On Sun, 23 May 2004, Simon Matter wrote: > >> I have just finished rebuilding my 2.2.4 rpms and I've got the same >> problem on my own server where I tested the build. I was able to access >> some folders but some others didn't work. > > Was there anything consistant about these folders (specifically, did they > have quotas associated with them)? > > Sadly, the backtrace you provided doesn't appear to be valid (why does > strcpy() call strcpy() and then call shut_down()? Hm, I think this one is correct. Sorry for the noise. (gdb) bt #0 0x080a0947 in hash_enumerate (table=0x8147de0, func=0x809d3c0 , rock=0xbfff9fe0) at hash.c:313 #1 0x0809d449 in commit_txn (db=0x8147dd8, tid=0x8147de0) at cyrusdb_quotalegacy.c:715 #2 0x0808bea5 in quota_commit (tid=0xbfffa07c) at quota_db.c:120 #3 0x0807215b in mailbox_expunge (mailbox=0x812dc00, iscurrentdir=1, decideproc=0, deciderock=0x0) at mailbox.c:1863 #4 0x08057dd4 in cmd_expunge (tag=0x81489a0 "A003", sequence=0x0) at imapd.c:3612 #5 0x08050980 in cmdloop () at imapd.c:1026 #6 0x0804f920 in service_main (argc=1, argv=0x813d410, envp=0xbfffe99c) at imapd.c:677 #7 0x0804df29 in main (argc=1, argv=0xbfffe994, envp=0xbfffe99c) at service.c:557 #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, ubp_av=0xbfffe994, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbfffe98c) at ../sysdeps/generic/libc-start.c:129 --- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
> On Sun, 23 May 2004, Simon Matter wrote: > >> I have just finished rebuilding my 2.2.4 rpms and I've got the same >> problem on my own server where I tested the build. I was able to access >> some folders but some others didn't work. > > Was there anything consistant about these folders (specifically, did they > have quotas associated with them)? > > Sadly, the backtrace you provided doesn't appear to be valid (why does > strcpy() call strcpy() and then call shut_down()? Is this one better: (gdb) bt #0 0x080a0947 in hash_enumerate () #1 0x0809d449 in commit_txn () #2 0x0808bea5 in quota_commit () #3 0x0807215b in mailbox_expunge () #4 0x08057dd4 in cmd_expunge () #5 0x08050980 in cmdloop () #6 0x0804f920 in service_main () #7 0x0804df29 in main () #8 0x40213657 in __libc_start_main (main=0x804d520 , argc=1, ubp_av=0xba14, init=0x804c0d4 <_init>, fini=0x80a3f50 <_fini>, rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xba0c) at ../sysdeps/generic/libc-start.c:129 Simon --- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
FYI, for me it happens everytime. I wanted to note that the crash does not happen always. Even on the same folder, sometimes it crashes, sometimes not. Simon --- 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: Problem w/ 2.2.4 and unixhierarchysep: yes
> On Sun, 23 May 2004, Simon Matter wrote: > >> I have just finished rebuilding my 2.2.4 rpms and I've got the same >> problem on my own server where I tested the build. I was able to access >> some folders but some others didn't work. > > Was there anything consistant about these folders (specifically, did they > have quotas associated with them)? There is a quota on 'user.simix'. No other quota on subfolders. > > Sadly, the backtrace you provided doesn't appear to be valid (why does > strcpy() call strcpy() and then call shut_down()? Well, that's what I was wondering about. At least I was able to catch an strace now which is attached. > > Was this a fresh install? No. > > Were you using unixhierarchysep? No, my imapd.conf: configdirectory: /var/lib/imap partition-default: /var/spool/imap admins: cyrus sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_ca_file: /usr/share/ssl/certs/ca-bundle.crt > > I can't duplicte this in any enviornment (upgraded, fresh install, > unixhierachysep or not). Perhaps if you attached a gdb > process to it and then made it crash it might be more illuminating than > looking at the core dump... Is it even possible with stripped binaries or do I have to rebuild? I wanted to note that the crash does not happen always. Even on the same folder, sometimes it crashes, sometimes not. Simon imapd.strace.gz Description: application/gzip
Re: mail server replication
Hi, Kevin P. Fleming wrote: drbd in combination with "heartbeat" and a journalling filesystem can do exactly this. You can have Cyrus IMAP running on both servers (different users), with the Cyrus storage areas mirrored to the other server via drbd. When heartbeat notices that one of the servers has died, it can mount the other server's storage area (since it has a copy) and start up Cyrus (and take over the other server's IP address as well, of course). Users would notice a service disruption, but it's not likely any mail would be lost and they would only have to reconnect. If their mail client is set to only connect/check their mailboxes every few minutes, they may not notice the switchover at all :-) Hmm, but this solution is only limited to linux (and if I'm correct only suitable for 2.4 kernels yet - I'm not sure about any developments, they talk about 2.5 on their website so it seems outdated as well). I would rather have Cyrus do this master-slave replication thing than doing this on the filesystem level. (Cyrus could for instance keep track of every change that is done on a specific spool-dir/partition, and have a slave act on that information...) Paul --- 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
