Re: Problem w/ 2.2.4 and unixhierarchysep: yes
I just tried this patch, and everything compile fine.
I wiped out my installation and mailbox partitions and started from
scratch with this new version. I ran into another problem right away.
When trying to do various cyradm operations, set ACL's and Deleting
mailboxes, cyradm will just hang. No errors, but it looks
like imapd just hangs, and the load on my box skyrockets until I stop
and restart master. Simon, did you try to install this version fresh?
Using RH 7.3 here.
I have tested patched 2.2.4 on my existing servers and also did a fresh
install with success. The tests were done on RedHat 7.2 and 7.3. I didn't
experience any problems.
Simon
Thanks.
AJ
Simon Matter wrote:
On Mon, 24 May 2004, Simon Matter wrote:
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?
Here is an ltrace in case this helps:
[snip]
Ok, the problem seems to be that we're deleteing elements of the hash
table in the middle of a call to hash_enumerate.
This isn't terribly good, but atleast I understand why its intermittant
and why Ken and I probably can't reproduce it (we're lucky).
Can one of you try this patch to hash.c?
Thanks! A quick test showed no problems so far. I'll do some more
testing
later today.
Simon
Index: hash.c
===
RCS file: /afs/andrew.cmu.edu/system/cvs/src/cyrus/lib/hash.c,v
retrieving revision 1.11
diff -u -r1.11 hash.c
--- hash.c 22 Oct 2003 18:50:12 - 1.11
+++ hash.c 24 May 2004 13:57:06 -
@@ -300,7 +300,7 @@
void *rock)
{
unsigned i;
- bucket *temp;
+ bucket *temp, *temp_next;
for (i=0;itable-size; i++)
{
@@ -308,8 +308,9 @@
{
for (temp = (table-table)[i];
NULL != temp;
-temp = temp - next)
+temp = temp_next)
{
+ temp_next = temp-next;
func(temp - key, temp-data, rock);
}
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
---
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? Here is an ltrace in case this helps: [pid 30323] fwrite(, 1, 764, 0x081523d0)= 764 [pid 30323] memcpy(0x08150bb0, , 60)= 0x08150bb0 [pid 30323] fwrite(, 1, 60, 0x08152260) = 60 [pid 30323] fwrite(, 1, 764, 0x081523d0)= 764 [pid 30323] memcpy(0x08150bb0, , 60)= 0x08150bb0 [pid 30323] fwrite(, 1, 60, 0x08152260) = 60 [pid 30323] fwrite(, 1, 764, 0x081523d0)= 764 [pid 30323] rewind(0x08152260, 1, 764, 0x081523d0, 0) = 0 [pid 30323] fread(0x08150bb0, 1, 76, 0x08152260) = 76 [pid 30323] rewind(0x08152260, 1, 764, 0x081523d0, 0) = 0 [pid 30323] fwrite(W\002\002\244, 1, 76, 0x08152260) = 76 [pid 30323] fflush(0x08152260)= 0 [pid 30323] fflush(0x081523d0)= 0 [pid 30323] ferror(0x08152260)= 0 [pid 30323] ferror(0x081523d0)= 0 [pid 30323] fileno(0x08152260)= 14 [pid 30323] fsync(14, 1, 764, 0x081523d0, 0) = 0 [pid 30323] fileno(0x081523d0)= 15 [pid 30323] fsync(15, 1, 764, 0x081523d0, 0) = 0 [pid 30323] strlen(0x0814fc60, 0x0811f301, 0xbfff9a98, 0x0808c8c2, 0x08152260) = 10 [pid 30323] snprintf(/var/lib/imap, 4097, %s, /var/lib/imap) = 13 [pid 30323] strchr(user.simix, '.') = .simix [pid 30323] snprintf(/quota/s/user.simix, 4084, %s%c/%s, /quota/, 's', user.simix) = 19 [pid 30323] open(/var/lib/imap/quota/s/user.simix, 2, 00) = 16 [pid 30323] fcntl(16, 7, 0xbfff8940, 0x080966c5, 0x40331e74) = 0 [pid 30323] __fxstat(3, 16, 0xbfff8990) = 0 [pid 30323] __xstat(3, /var/lib/imap/quota/s/user.simix, 0xbfff88e0) = 0 [pid 30323] malloc(16)= 0x08150c00 [pid 30323] malloc(12)= 0x0814fc70 [pid 30323] strlen(0xbfff8a30, 0, 0xbfff8938, 0x0809faaf, 12) = 32 [pid 30323] malloc(33)= 0x08150268 [pid 30323] strcpy(0x08150268, /var/lib/imap/quota/s/user.simix) = 0x08150268 [pid 30323] __fxstat(3, 16, 0xbfff88e0) = 0 [pid 30323] mmap(0, 12, 1, 1, 16) = 0x414e4000 [pid 30323] realloc(0x0814fc50, 12) = 0x0814fc50 [pid 30323] memcpy(0x0814fc50, 463034\n1000\n, 12) = 0x0814fc50 [pid 30323] memchr(463034\n1000\n\021, '\n', 12) = 0x0814fc56 [pid 30323] memchr(1000\n\021, '\n', 5) = 0x0814fc5b [pid 30323] strlen(0x0814fc50, 10, 5, 0xbfff898c, 0xbfff8984) = 11 [pid 30323] munmap(0x414e4000, 12, 0xbfff8968, 0x08096b8e, 0x0814fc50) = 0 [pid 30323] sscanf(0x0814fc50, 0x0811bcf2, 0x0812e96c, 0x0812e970, 0x08152260) = 2 [pid 30323] strlen(0x0814fc60, 0xbfff9afc, 0, 0x0808ca81, 0x30333634) = 10 [pid 30323] snprintf(463034 1000, 1023, %lu %d, 463034, 1000) = 11 [pid 30323] snprintf(/var/lib/imap, 4097, %s, /var/lib/imap) = 13 [pid 30323] strchr(user.simix, '.') = .simix [pid 30323] snprintf(/quota/s/user.simix, 4084, %s%c/%s, /quota/, 's', user.simix) = 19 [pid 30323] strcmp(/var/lib/imap/quota/s/user.simix, /var/lib/imap/quota/s/user.simix) = 0 [pid 30323] strlen(0xbfff7590, 0x08150268, 0xbfff7568, 0x0809fc2e, 0x0811f5f2) = 32 [pid 30323] unlink(/var/lib/imap/quota/s/user.simix...) = -1 [pid 30323] open(/var/lib/imap/quota/s/user.simix..., 578, 0666) = 17 [pid 30323] fcntl(17, 7, 0xbfff7540, 0x0809683e, 1) = 0 [pid 30323] malloc(12)= 0x08150c18 [pid 30323] memcpy(0x08150c18, 463034 1000, 11) = 0x08150c18 [pid 30323] memchr(463034 100078, ' ', 11) = 0x08150c1e [pid 30323] write(17, 463034\n1000\n, 12) = 12 [pid 30323] free(0x08150c18) = void [pid 30323] strlen(0xbfff7590, 0x40330340, 0xbfff7568, 0x4027c3f4, 12) = 36 [pid 30323] malloc(37)= 0x08151df0 [pid 30323] strcpy(0x08151df0, /var/lib/imap/quota/s/user.simix...) = 0x08151df0 [pid 30323] fsync(17, 0x0811bcf2, 0xbfff9a78, 0x0809ce0e, 0xbfff9990) = 0 [pid 30323] __fxstat(3, 17, 0xbfff9980)
Re: Problem w/ 2.2.4 and unixhierarchysep: yes
On Mon, 24 May 2004, Simon Matter wrote:
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?
Here is an ltrace in case this helps:
[snip]
Ok, the problem seems to be that we're deleteing elements of the hash
table in the middle of a call to hash_enumerate.
This isn't terribly good, but atleast I understand why its intermittant
and why Ken and I probably can't reproduce it (we're lucky).
Can one of you try this patch to hash.c?
Index: hash.c
===
RCS file: /afs/andrew.cmu.edu/system/cvs/src/cyrus/lib/hash.c,v
retrieving revision 1.11
diff -u -r1.11 hash.c
--- hash.c 22 Oct 2003 18:50:12 - 1.11
+++ hash.c 24 May 2004 13:57:06 -
@@ -300,7 +300,7 @@
void *rock)
{
unsigned i;
- bucket *temp;
+ bucket *temp, *temp_next;
for (i=0;itable-size; i++)
{
@@ -308,8 +308,9 @@
{
for (temp = (table-table)[i];
NULL != temp;
-temp = temp - next)
+temp = temp_next)
{
+ temp_next = temp-next;
func(temp - key, temp-data, rock);
}
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
---
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
Hi all, i am new subscriber here, so sorry for replying in this form. 2 days ago i tryed Cyrus-Imapd-2.2.4 on two host. And get same problem : lmtp crash with BUSY error. But only for one host, and not allways(on same user).I donwgraded to 2.2.3. For another host all works ok up to today with 2.2.4. It's not quota problem, i have crash even on users who dont have set quota at all. DB is not corrupt, its works with 2.2.3 fine. I also tryed to reconstruct mailboxes, but it gives no changes. Same times emails comes throw, sametimes i get Defered... message in sendmail output and sigfault 11 for BUSY reason in syslog. Crashhost is very similar to another one: x86 mashine with 2.4 kernel - ext3 used as storage, compiled against BerkleyDB 4.2.52 with 2 patches. PC where all works just fine: x86 mashine with 2.4 kernel - reiserfs used as storage, compiled against BerkleyDB 4.0.14 Hope my mail help somehow... PS. sorry for my bad english... -- Teresa Kalitowska mailto:[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: 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? Okay, while playing again I found the following: - RedHat 7.2 on XFS doesn't work too - RedHat 9 on EXT3 works fine I tested it by copying /var/spool/imap and /var/lib/imap to the RH9 box. Is there anything in the changes since 2.2.3 which could break compatibility with older gcc like 2.9.x version, or glibc or whatever? (cyrus-sasl is 2.2.18 on both). I'm quite sure more people will be hit by this problem once they start to upgrade to 2.2.4. Simon Here is an ltrace in case this helps: [pid 30323] fwrite(, 1, 764, 0x081523d0)= 764 [pid 30323] memcpy(0x08150bb0, , 60)= 0x08150bb0 [pid 30323] fwrite(, 1, 60, 0x08152260) = 60 [pid 30323] fwrite(, 1, 764, 0x081523d0)= 764 [pid 30323] memcpy(0x08150bb0, , 60)= 0x08150bb0 [pid 30323] fwrite(, 1, 60, 0x08152260) = 60 [pid 30323] fwrite(, 1, 764, 0x081523d0)= 764 [pid 30323] rewind(0x08152260, 1, 764, 0x081523d0, 0) = 0 [pid 30323] fread(0x08150bb0, 1, 76, 0x08152260) = 76 [pid 30323] rewind(0x08152260, 1, 764, 0x081523d0, 0) = 0 [pid 30323] fwrite(W\002\002\244, 1, 76, 0x08152260) = 76 [pid 30323] fflush(0x08152260)= 0 [pid 30323] fflush(0x081523d0)= 0 [pid 30323] ferror(0x08152260)= 0 [pid 30323] ferror(0x081523d0)= 0 [pid 30323] fileno(0x08152260)= 14 [pid 30323] fsync(14, 1, 764, 0x081523d0, 0) = 0 [pid 30323] fileno(0x081523d0)= 15 [pid 30323] fsync(15, 1, 764, 0x081523d0, 0) = 0 [pid 30323] strlen(0x0814fc60, 0x0811f301, 0xbfff9a98, 0x0808c8c2, 0x08152260) = 10 [pid 30323] snprintf(/var/lib/imap, 4097, %s, /var/lib/imap) = 13 [pid 30323] strchr(user.simix, '.') = .simix [pid 30323] snprintf(/quota/s/user.simix, 4084, %s%c/%s, /quota/, 's', user.simix) = 19 [pid 30323] open(/var/lib/imap/quota/s/user.simix, 2, 00) = 16 [pid 30323] fcntl(16, 7, 0xbfff8940, 0x080966c5, 0x40331e74) = 0 [pid 30323] __fxstat(3, 16, 0xbfff8990) = 0 [pid 30323] __xstat(3, /var/lib/imap/quota/s/user.simix, 0xbfff88e0) = 0 [pid 30323] malloc(16)= 0x08150c00 [pid 30323] malloc(12)= 0x0814fc70 [pid 30323] strlen(0xbfff8a30, 0, 0xbfff8938, 0x0809faaf, 12) = 32 [pid 30323] malloc(33)= 0x08150268 [pid 30323] strcpy(0x08150268, /var/lib/imap/quota/s/user.simix) 0x08150268 [pid 30323] __fxstat(3, 16, 0xbfff88e0) = 0 [pid 30323] mmap(0, 12, 1, 1, 16) = 0x414e4000 [pid 30323] realloc(0x0814fc50, 12) = 0x0814fc50 [pid 30323] memcpy(0x0814fc50, 463034\n1000\n, 12) = 0x0814fc50 [pid 30323] memchr(463034\n1000\n\021, '\n', 12) = 0x0814fc56 [pid 30323] memchr(1000\n\021, '\n', 5) = 0x0814fc5b [pid 30323] strlen(0x0814fc50, 10, 5, 0xbfff898c, 0xbfff8984) = 11 [pid 30323] munmap(0x414e4000, 12, 0xbfff8968, 0x08096b8e, 0x0814fc50) = 0 [pid 30323] sscanf(0x0814fc50, 0x0811bcf2, 0x0812e96c, 0x0812e970, 0x08152260) = 2 [pid 30323] strlen(0x0814fc60, 0xbfff9afc, 0, 0x0808ca81, 0x30333634) = 10 [pid 30323] snprintf(463034 1000, 1023, %lu %d, 463034, 1000) = 11 [pid 30323] snprintf(/var/lib/imap, 4097, %s, /var/lib/imap) = 13 [pid 30323] strchr(user.simix, '.') = .simix [pid 30323] snprintf(/quota/s/user.simix, 4084, %s%c/%s, /quota/, 's', user.simix) = 19 [pid 30323] strcmp(/var/lib/imap/quota/s/user.simix, /var/lib/imap/quota/s/user.simix) = 0 [pid 30323] strlen(0xbfff7590, 0x08150268, 0xbfff7568, 0x0809fc2e, 0x0811f5f2) = 32 [pid 30323] unlink(/var/lib/imap/quota/s/user.simix...) = -1 [pid 30323] open(/var/lib/imap/quota/s/user.simix..., 578, 0666) = 17 [pid 30323] fcntl(17, 7, 0xbfff7540, 0x0809683e, 1) = 0 [pid 30323] malloc(12)= 0x08150c18 [pid 30323] memcpy(0x08150c18, 463034 1000, 11)
Re: Problem w/ 2.2.4 and unixhierarchysep: yes
On Mon, 24 May 2004, Simon Matter wrote:
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?
Here is an ltrace in case this helps:
[snip]
Ok, the problem seems to be that we're deleteing elements of the hash
table in the middle of a call to hash_enumerate.
This isn't terribly good, but atleast I understand why its intermittant
and why Ken and I probably can't reproduce it (we're lucky).
Can one of you try this patch to hash.c?
Thanks! A quick test showed no problems so far. I'll do some more testing
later today.
Simon
Index: hash.c
===
RCS file: /afs/andrew.cmu.edu/system/cvs/src/cyrus/lib/hash.c,v
retrieving revision 1.11
diff -u -r1.11 hash.c
--- hash.c 22 Oct 2003 18:50:12 - 1.11
+++ hash.c 24 May 2004 13:57:06 -
@@ -300,7 +300,7 @@
void *rock)
{
unsigned i;
- bucket *temp;
+ bucket *temp, *temp_next;
for (i=0;itable-size; i++)
{
@@ -308,8 +308,9 @@
{
for (temp = (table-table)[i];
NULL != temp;
-temp = temp - next)
+temp = temp_next)
{
+ temp_next = temp-next;
func(temp - key, temp-data, rock);
}
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
---
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
Hi all, Not trying to steal the tread ;-) But i hope additional/other info could be helpfull ? For the last couple of days i try to upgrade a FreeBSD 4.9 box from 2.2.3 to 2.2.4 ... Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) Another testserver with both options disabled worked right away. So, without any solid proof it looks like unixhierarchysep is playing up for sieve as well ?? Discard this when you think this is useless, but it might not be .. Best regards, Bob --- 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 Mon, 24 May 2004, Bob Tito wrote: Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) The scripts were just ignored -- does that mean that discard, reject, redirect, and vacation actions all failed, or was it just fileinto that was failing? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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
Bob Tito wrote: Hi all, Not trying to steal the tread ;-) But i hope additional/other info could be helpfull ? For the last couple of days i try to upgrade a FreeBSD 4.9 box from 2.2.3 to 2.2.4 ... Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) I can't reproduce this. I just tested all 4 combinations of altnamespace and unixhierarchysep and they all worked fine with 2.2.4. -- 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
Ken Murchison wrote: Bob Tito wrote: Hi all, Not trying to steal the tread ;-) But i hope additional/other info could be helpfull ? For the last couple of days i try to upgrade a FreeBSD 4.9 box from 2.2.3 to 2.2.4 ... Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) I can't reproduce this. I just tested all 4 combinations of altnamespace and unixhierarchysep and they all worked fine with 2.2.4. Duh... So, there *might* be something wrong with the current version, but at random and not reproducable in a number of cases .. Do you mind that i stick to 2.2.3 for now ? ;-) This week we'll have a go at 2.2.4 on a testsystem running Solaris. With Altnamespace but without unixhierarchysep. I'll have a close look at sieve. The FreeBSD box is my own, so not such a big deal, the one solaris needs to host 12000 users... Any recommendations at this moment ? carry on or wait a few days ? Best regards, Bob --- 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
Bob Tito wrote: Hi all, Not trying to steal the tread ;-) But i hope additional/other info could be helpfull ? For the last couple of days i try to upgrade a FreeBSD 4.9 box from 2.2.3 to 2.2.4 ... Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) I can't reproduce this. I just tested all 4 combinations of altnamespace and unixhierarchysep and they all worked fine with 2.2.4. The hash_enumerate() function is also used by some other cyrus-imapd programs so I could think, without having a closer look, that it could also break other programs, right? I suggest testing it on a affected platform with the patch applied. BTW, do you, the developers, plan to push out another release like 2.2.5 if the patch discussed here fixes the problem? I just want to know whether I should wait for it before publishing updated rpms. Thanks, Simon -- 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 --- 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: Bob Tito wrote: Hi all, Not trying to steal the tread ;-) But i hope additional/other info could be helpfull ? For the last couple of days i try to upgrade a FreeBSD 4.9 box from 2.2.3 to 2.2.4 ... Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) I can't reproduce this. I just tested all 4 combinations of altnamespace and unixhierarchysep and they all worked fine with 2.2.4. The hash_enumerate() function is also used by some other cyrus-imapd programs so I could think, without having a closer look, that it could also break other programs, right? I suggest testing it on a affected platform with the patch applied. Obviously a fileinto needs to touch the quota code, so the hash problem is a possibility. But I would suspect that if this were the case that it wouldn't be limited to just fileinto -- *any* message delivery would cause a problem. BTW, do you, the developers, plan to push out another release like 2.2.5 if the patch discussed here fixes the problem? I just want to know whether I should wait for it before publishing updated rpms. My guess would be that Rob will cut a 2.2.5 release once these issues are fixed. -- 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 Mon, 24 May 2004, Ken Murchison wrote: The hash_enumerate() function is also used by some other cyrus-imapd programs so I could think, without having a closer look, that it could also break other programs, right? I suggest testing it on a affected platform with the patch applied. Obviously a fileinto needs to touch the quota code, so the hash problem is a possibility. But I would suspect that if this were the case that it wouldn't be limited to just fileinto -- *any* message delivery would cause a problem. I suspect the hash_enumerate issue would crash the process if it had any effect at all (and it would crash at the same point as it was crashing for the quotadb issue). I don't think, offhand, that the two issues (if any) are related. Simon -- have you seen the sieve problem? BTW, do you, the developers, plan to push out another release like 2.2.5 if the patch discussed here fixes the problem? I just want to know whether I should wait for it before publishing updated rpms. My guess would be that Rob will cut a 2.2.5 release once these issues are fixed. That's my plan. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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 Mon, 24 May 2004, Ken Murchison wrote: The hash_enumerate() function is also used by some other cyrus-imapd programs so I could think, without having a closer look, that it could also break other programs, right? I suggest testing it on a affected platform with the patch applied. Obviously a fileinto needs to touch the quota code, so the hash problem is a possibility. But I would suspect that if this were the case that it wouldn't be limited to just fileinto -- *any* message delivery would cause a problem. I suspect the hash_enumerate issue would crash the process if it had any effect at all (and it would crash at the same point as it was crashing for the quotadb issue). I don't think, offhand, that the two issues (if any) are related. Simon -- have you seen the sieve problem? In fact I was unable to test further because my box was almost unusable. And I don't use unixhierachysep nor altnamespace. I had in mind that Bob mentioned the famous 'signaled to death by 11' but after rereading I know it's not the case. Simon BTW, do you, the developers, plan to push out another release like 2.2.5 if the patch discussed here fixes the problem? I just want to know whether I should wait for it before publishing updated rpms. My guess would be that Rob will cut a 2.2.5 release once these issues are fixed. That's my plan. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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: Bob Tito wrote: Hi all, Not trying to steal the tread ;-) But i hope additional/other info could be helpfull ? For the last couple of days i try to upgrade a FreeBSD 4.9 box from 2.2.3 to 2.2.4 ... Luckally i did not have the problems described here, but NO WAY i was able to get sieve working with unixhierachysep and altnamespace enabled.. The scripts were just ignored.. reverting back to 2.2.3 solved the problem right away. I disabled altnamespace, but that didn't solve the problem, even after ajusting the scripts to te corrected mailbox location. I was not able to disable unixhierarchsep, because of live mailboxes ;-) I can't reproduce this. I just tested all 4 combinations of altnamespace and unixhierarchysep and they all worked fine with 2.2.4. The hash_enumerate() function is also used by some other cyrus-imapd programs so I could think, without having a closer look, that it could also break other programs, right? I suggest testing it on a affected platform with the patch applied. Obviously a fileinto needs to touch the quota code, so the hash problem is a possibility. But I would suspect that if this were the case that it wouldn't be limited to just fileinto -- *any* message delivery would cause a problem. BTW, do you, the developers, plan to push out another release like 2.2.5 if the patch discussed here fixes the problem? I just want to know whether I should wait for it before publishing updated rpms. My guess would be that Rob will cut a 2.2.5 release once these issues are fixed. The problem with the hash_enumerate issue is solved for me. Thanks, Simon -- 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
I just tried this patch, and everything compile fine.
I wiped out my installation and mailbox partitions and started from
scratch with this new version. I ran into another problem right away.
When trying to do various cyradm operations, set ACL's and Deleting
mailboxes, cyradm will just hang. No errors, but it looks
like imapd just hangs, and the load on my box skyrockets until I stop
and restart master. Simon, did you try to install this version fresh?
Using RH 7.3 here.
Thanks.
AJ
Simon Matter wrote:
On Mon, 24 May 2004, Simon Matter wrote:
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?
Here is an ltrace in case this helps:
[snip]
Ok, the problem seems to be that we're deleteing elements of the hash
table in the middle of a call to hash_enumerate.
This isn't terribly good, but atleast I understand why its intermittant
and why Ken and I probably can't reproduce it (we're lucky).
Can one of you try this patch to hash.c?
Thanks! A quick test showed no problems so far. I'll do some more testing
later today.
Simon
Index: hash.c
===
RCS file: /afs/andrew.cmu.edu/system/cvs/src/cyrus/lib/hash.c,v
retrieving revision 1.11
diff -u -r1.11 hash.c
--- hash.c 22 Oct 2003 18:50:12 - 1.11
+++ hash.c 24 May 2004 13:57:06 -
@@ -300,7 +300,7 @@
void *rock)
{
unsigned i;
- bucket *temp;
+ bucket *temp, *temp_next;
for (i=0;itable-size; i++)
{
@@ -308,8 +308,9 @@
{
for (temp = (table-table)[i];
NULL != temp;
-temp = temp - next)
+temp = temp_next)
{
+ temp_next = temp-next;
func(temp - key, temp-data, rock);
}
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
---
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 Mon, 24 May 2004, AJ wrote: I just tried this patch, and everything compile fine. I wiped out my installation and mailbox partitions and started from scratch with this new version. I ran into another problem right away. When trying to do various cyradm operations, set ACL's and Deleting mailboxes, cyradm will just hang. No errors, but it looks like imapd just hangs, and the load on my box skyrockets until I stop and restart master. Simon, did you try to install this version fresh? Using RH 7.3 here. What does strace on the affected imapd process reveal? It sounds like some lock is being held too long that shouldn't be. (Do you have old imapd's lying around?) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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
Rob, I reverted back again, I need to keep the box up for some folks to test a new web interface for a few days, they are already shouting at me. :) I know for a fact there were no stale imapd's around, I checked that out when this happened, and completely removed the old /usr/cyrus/bin folder before testing. I will see if I can get an strace for you ASAP, anyone else see this issue? Thanks. AJ Rob Siemborski wrote: On Mon, 24 May 2004, AJ wrote: I just tried this patch, and everything compile fine. I wiped out my installation and mailbox partitions and started from scratch with this new version. I ran into another problem right away. When trying to do various cyradm operations, set ACL's and Deleting mailboxes, cyradm will just hang. No errors, but it looks like imapd just hangs, and the load on my box skyrockets until I stop and restart master. Simon, did you try to install this version fresh? Using RH 7.3 here. What does strace on the affected imapd process reveal? It sounds like some lock is being held too long that shouldn't be. (Do you have old imapd's lying around?) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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: 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)? 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 main, 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
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 enum_func, 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 main, 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
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 enum_func, 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 main, 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? 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 enum_func, 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 main, 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? 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 enum_func, 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 main, 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
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: 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 enum_func, 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 main, 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: 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 enum_func, 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 main, 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: Problem w/ 2.2.4 and unixhierarchysep: yes
Rob, There is no core dumped from what I can tell, it looks like master just dies for that process. Did you test this on a clean install of 2.2.4, and clean partitions and config directories. This does not seem to occur on an install of 2.2.4 that was upgraded i.e., the mailboxes and database were not created from scratch. It's odd. Let me know. AJ Rob Siemborski wrote: There were substantial changes in the handling of quotas in 2.2.4. However, we're unable to replicate your problem. Can you generate a GDB backtrace from a core dump to show where the segfault is occuring? On Fri, 21 May 2004, AJ wrote: This problem does not appear in 2.2.3, I just wiped my entire 2.2.4 install and installed 2.2.3 and no issues. Ideas? AJ AJ wrote: The pieces begin to come together here.. hopefully someone else benefits from this post. I have managed to track the problem down to not just accounts with a dot in the mailbox name. This problem is occuring on mailboxes with quotas only. Mailboxes that do not have quotas do not experience this issue. My imapd.conf file is below, does anyone know why this is happening? Once I issue these command in cyradm, this issue happens for the mary.jones mailbox. localhost sq user/mary.smith 8192 quota:8192 localhost lq user/mary.smith STORAGE 1/8192 (0.01220703125%) Here is imapd.conf: configdirectory: /var/cyrus/imap partition-default: /var/cyrus/spool/imap admins: cyrus sievedir: /var/cyrus/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN altnamespace: yes unixhierarchysep: yes Thanks. AJ AJ wrote: Here is an odd update to this... I tried to create another user with a dot and it works fine. It seems john.smith causes the error whereas al.jones does not. Has anyone seen anything like this? Thanks. AJ AJ wrote: Hi, I have an odd problem. I am running 2.2.4 fresh install and I have an issue when using a mailbox with a . in the name, such as user/john.smith I have the unixhierarchysep: yes line in my imapd.conf. Whenever I try to delete a message or move a message to another folder with this mailbox, I generate these errors: May 21 18:44:58 linux-beta master[2745]: process 2753 exited, signaled to death by 11 May 21 18:44:58 linux-beta master[2745]: service imap pid 2753 in BUSY state: terminated abnormally And I get errors on the client that said the connection was terminated before the command could complete. It looks like the files get copied but not moved, so it appears to be a delete issue. Users that do not have a . in their mailbox name do not have this problem. Has anyone seen this? I have another version of 2.2.4 running, and this does not happen there, but that version was upgraded. The only other difference is that the version that has this issue is running bdb 4.2.x and the other system is running 4.1.x. I just wanted to throw this out there to see if anyone knows anything about this. Thanks. AJ --- 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 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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
Rob, There is no core dumped from what I can tell, it looks like master just dies for that process. Did you test this on a clean install of 2.2.4, and clean partitions and config directories. This does not seem to occur on an install of 2.2.4 that was upgraded i.e., the mailboxes and database were not created from scratch. It's odd. Hi 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. May 23 02:50:25 xxl imap[1826]: login: localhost.localdomain [127.0.0.1] simix plaintext User logged in May 23 02:50:25 xxl imap[1928]: executed May 23 02:50:25 xxl imap[1826]: seen_db: user simix opened /var/lib/imap/user/s/simix.seen May 23 02:50:25 xxl imap[1826]: open: user simix opened INBOX May 23 02:50:25 xxl master[1794]: process 1826 exited, signaled to death by 11 May 23 02:50:25 xxl master[1794]: service imap pid 1826 in BUSY state: terminated abnormally This is on RedHat 7.2 with db3, so no db4 issue here. The error I get from Squirrelmail is: ERROR : Connection dropped by imap-server. Query: EXPUNGE I have tried to produce a backtrace like this: [EMAIL PROTECTED] tmp]# gdb imapd core GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux...(no debugging symbols found)... Core was generated by `imapd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libssl.so.2...done. Loaded symbols for /lib/libssl.so.2 Reading symbols from /lib/libcrypto.so.2...done. Loaded symbols for /lib/libcrypto.so.2 Reading symbols from /lib/libdb-3.2.so...done. Loaded symbols for /lib/libdb-3.2.so Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_nisplus.so.2...done. Loaded symbols for /lib/libnss_nisplus.so.2 #0 0x080a0987 in xrealloc () (gdb) bt #0 0x080a0987 in xrealloc () #1 0x0809d489 in mboxlist_findsub_alt () #2 0x0808bee5 in mboxlist_findsub_alt () #3 0x0807219b in cyrus_mutex_free () #4 0x08057dd4 in idle_update () #5 0x08050980 in shut_down () #6 0x0804f920 in strcpy () at strcpy:-1 #7 0x0804df29 in strcpy () at strcpy:-1 #8 0x40213657 in __libc_start_main (main=0x804d520 strcpy+1284, argc=1, ubp_av=0xbfffe124, init=0x804c0d4 _init, fini=0x80a3f90 _fini, rtld_fini=0x4000dc54 _dl_fini, stack_end=0xbfffe11c) at ../sysdeps/generic/libc-start.c:129 (gdb) Regards, Simon Let me know. AJ Rob Siemborski wrote: There were substantial changes in the handling of quotas in 2.2.4. However, we're unable to replicate your problem. Can you generate a GDB backtrace from a core dump to show where the segfault is occuring? On Fri, 21 May 2004, AJ wrote: This problem does not appear in 2.2.3, I just wiped my entire 2.2.4 install and installed 2.2.3 and no issues. Ideas? AJ AJ wrote: The pieces begin to come together here.. hopefully someone else benefits from this post. I have managed to track the problem down to not just accounts with a dot in the mailbox name. This problem is occuring on mailboxes with quotas only. Mailboxes that do not have quotas do not experience this issue. My imapd.conf file is below, does anyone know why this is happening? Once I issue these command in cyradm, this issue happens for the mary.jones mailbox. localhost sq
Re: Problem w/ 2.2.4 and unixhierarchysep: yes
Yes, the same thing happens here.. connection just drops. I have reverted back to 2.2.3. Simon Matter wrote: Rob, There is no core dumped from what I can tell, it looks like master just dies for that process. Did you test this on a clean install of 2.2.4, and clean partitions and config directories. This does not seem to occur on an install of 2.2.4 that was upgraded i.e., the mailboxes and database were not created from scratch. It's odd. Hi 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. May 23 02:50:25 xxl imap[1826]: login: localhost.localdomain [127.0.0.1] simix plaintext User logged in May 23 02:50:25 xxl imap[1928]: executed May 23 02:50:25 xxl imap[1826]: seen_db: user simix opened /var/lib/imap/user/s/simix.seen May 23 02:50:25 xxl imap[1826]: open: user simix opened INBOX May 23 02:50:25 xxl master[1794]: process 1826 exited, signaled to death by 11 May 23 02:50:25 xxl master[1794]: service imap pid 1826 in BUSY state: terminated abnormally This is on RedHat 7.2 with db3, so no db4 issue here. The error I get from Squirrelmail is: ERROR : Connection dropped by imap-server. Query: EXPUNGE I have tried to produce a backtrace like this: [EMAIL PROTECTED] tmp]# gdb imapd core GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux...(no debugging symbols found)... Core was generated by `imapd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libssl.so.2...done. Loaded symbols for /lib/libssl.so.2 Reading symbols from /lib/libcrypto.so.2...done. Loaded symbols for /lib/libcrypto.so.2 Reading symbols from /lib/libdb-3.2.so...done. Loaded symbols for /lib/libdb-3.2.so Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_nisplus.so.2...done. Loaded symbols for /lib/libnss_nisplus.so.2 #0 0x080a0987 in xrealloc () (gdb) bt #0 0x080a0987 in xrealloc () #1 0x0809d489 in mboxlist_findsub_alt () #2 0x0808bee5 in mboxlist_findsub_alt () #3 0x0807219b in cyrus_mutex_free () #4 0x08057dd4 in idle_update () #5 0x08050980 in shut_down () #6 0x0804f920 in strcpy () at strcpy:-1 #7 0x0804df29 in strcpy () at strcpy:-1 #8 0x40213657 in __libc_start_main (main=0x804d520 strcpy+1284, argc=1, ubp_av=0xbfffe124, init=0x804c0d4 _init, fini=0x80a3f90 _fini, rtld_fini=0x4000dc54 _dl_fini, stack_end=0xbfffe11c) at ../sysdeps/generic/libc-start.c:129 (gdb) Regards, Simon Let me know. AJ Rob Siemborski wrote: There were substantial changes in the handling of quotas in 2.2.4. However, we're unable to replicate your problem. Can you generate a GDB backtrace from a core dump to show where the segfault is occuring? On Fri, 21 May 2004, AJ wrote: This problem does not appear in 2.2.3, I just wiped my entire 2.2.4 install and installed 2.2.3 and no issues. Ideas? AJ AJ wrote: The pieces begin to come together here.. hopefully someone else benefits from this post. I have managed to track the problem down to not just accounts with a dot in the mailbox name. This problem is occuring on mailboxes with quotas only. Mailboxes that do not have quotas do not experience this issue. My imapd.conf file is below, does anyone know why this is happening? Once I issue these command in
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()? Was this a fresh install? Were you using unixhierarchysep? 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... -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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
Rob, Here are the details of my setup: This only happens on mailboxes with quotas. This was a fresh install, it did not seem to occur on an upgraded install. I was using unixhierarchysep. Simon, can you help with a gdb dump? I have no access to the system I was using until Monday. Thanks. AJ Rob Siemborski 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()? Was this a fresh install? Were you using unixhierarchysep? 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... -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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
Here is an odd update to this... I tried to create another user with a dot and it works fine. It seems john.smith causes the error whereas al.jones does not. Has anyone seen anything like this? Thanks. AJ AJ wrote: Hi, I have an odd problem. I am running 2.2.4 fresh install and I have an issue when using a mailbox with a . in the name, such as user/john.smith I have the unixhierarchysep: yes line in my imapd.conf. Whenever I try to delete a message or move a message to another folder with this mailbox, I generate these errors: May 21 18:44:58 linux-beta master[2745]: process 2753 exited, signaled to death by 11 May 21 18:44:58 linux-beta master[2745]: service imap pid 2753 in BUSY state: terminated abnormally And I get errors on the client that said the connection was terminated before the command could complete. It looks like the files get copied but not moved, so it appears to be a delete issue. Users that do not have a . in their mailbox name do not have this problem. Has anyone seen this? I have another version of 2.2.4 running, and this does not happen there, but that version was upgraded. The only other difference is that the version that has this issue is running bdb 4.2.x and the other system is running 4.1.x. I just wanted to throw this out there to see if anyone knows anything about this. Thanks. AJ --- 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 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
The pieces begin to come together here.. hopefully someone else benefits from this post. I have managed to track the problem down to not just accounts with a dot in the mailbox name. This problem is occuring on mailboxes with quotas only. Mailboxes that do not have quotas do not experience this issue. My imapd.conf file is below, does anyone know why this is happening? Once I issue these command in cyradm, this issue happens for the mary.jones mailbox. localhost sq user/mary.smith 8192 quota:8192 localhost lq user/mary.smith STORAGE 1/8192 (0.01220703125%) Here is imapd.conf: configdirectory: /var/cyrus/imap partition-default: /var/cyrus/spool/imap admins: cyrus sievedir: /var/cyrus/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN altnamespace: yes unixhierarchysep: yes Thanks. AJ AJ wrote: Here is an odd update to this... I tried to create another user with a dot and it works fine. It seems john.smith causes the error whereas al.jones does not. Has anyone seen anything like this? Thanks. AJ AJ wrote: Hi, I have an odd problem. I am running 2.2.4 fresh install and I have an issue when using a mailbox with a . in the name, such as user/john.smith I have the unixhierarchysep: yes line in my imapd.conf. Whenever I try to delete a message or move a message to another folder with this mailbox, I generate these errors: May 21 18:44:58 linux-beta master[2745]: process 2753 exited, signaled to death by 11 May 21 18:44:58 linux-beta master[2745]: service imap pid 2753 in BUSY state: terminated abnormally And I get errors on the client that said the connection was terminated before the command could complete. It looks like the files get copied but not moved, so it appears to be a delete issue. Users that do not have a . in their mailbox name do not have this problem. Has anyone seen this? I have another version of 2.2.4 running, and this does not happen there, but that version was upgraded. The only other difference is that the version that has this issue is running bdb 4.2.x and the other system is running 4.1.x. I just wanted to throw this out there to see if anyone knows anything about this. Thanks. AJ --- 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 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
AJ wrote: Here is an odd update to this... I tried to create another user with a dot and it works fine. It seems john.smith causes the error whereas al.jones does not. Has anyone seen anything like this? user/john.smith may be corrupt in some way. Try reconstructing the mailbox and see what happens. AJ wrote: Hi, I have an odd problem. I am running 2.2.4 fresh install and I have an issue when using a mailbox with a . in the name, such as user/john.smith I have the unixhierarchysep: yes line in my imapd.conf. Whenever I try to delete a message or move a message to another folder with this mailbox, I generate these errors: May 21 18:44:58 linux-beta master[2745]: process 2753 exited, signaled to death by 11 May 21 18:44:58 linux-beta master[2745]: service imap pid 2753 in BUSY state: terminated abnormally And I get errors on the client that said the connection was terminated before the command could complete. It looks like the files get copied but not moved, so it appears to be a delete issue. Users that do not have a . in their mailbox name do not have this problem. Has anyone seen this? I have another version of 2.2.4 running, and this does not happen there, but that version was upgraded. The only other difference is that the version that has this issue is running bdb 4.2.x and the other system is running 4.1.x. I just wanted to throw this out there to see if anyone knows anything about this. Thanks. AJ --- 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 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
There were substantial changes in the handling of quotas in 2.2.4. However, we're unable to replicate your problem. Can you generate a GDB backtrace from a core dump to show where the segfault is occuring? On Fri, 21 May 2004, AJ wrote: This problem does not appear in 2.2.3, I just wiped my entire 2.2.4 install and installed 2.2.3 and no issues. Ideas? AJ AJ wrote: The pieces begin to come together here.. hopefully someone else benefits from this post. I have managed to track the problem down to not just accounts with a dot in the mailbox name. This problem is occuring on mailboxes with quotas only. Mailboxes that do not have quotas do not experience this issue. My imapd.conf file is below, does anyone know why this is happening? Once I issue these command in cyradm, this issue happens for the mary.jones mailbox. localhost sq user/mary.smith 8192 quota:8192 localhost lq user/mary.smith STORAGE 1/8192 (0.01220703125%) Here is imapd.conf: configdirectory: /var/cyrus/imap partition-default: /var/cyrus/spool/imap admins: cyrus sievedir: /var/cyrus/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN altnamespace: yes unixhierarchysep: yes Thanks. AJ AJ wrote: Here is an odd update to this... I tried to create another user with a dot and it works fine. It seems john.smith causes the error whereas al.jones does not. Has anyone seen anything like this? Thanks. AJ AJ wrote: Hi, I have an odd problem. I am running 2.2.4 fresh install and I have an issue when using a mailbox with a . in the name, such as user/john.smith I have the unixhierarchysep: yes line in my imapd.conf. Whenever I try to delete a message or move a message to another folder with this mailbox, I generate these errors: May 21 18:44:58 linux-beta master[2745]: process 2753 exited, signaled to death by 11 May 21 18:44:58 linux-beta master[2745]: service imap pid 2753 in BUSY state: terminated abnormally And I get errors on the client that said the connection was terminated before the command could complete. It looks like the files get copied but not moved, so it appears to be a delete issue. Users that do not have a . in their mailbox name do not have this problem. Has anyone seen this? I have another version of 2.2.4 running, and this does not happen there, but that version was upgraded. The only other difference is that the version that has this issue is running bdb 4.2.x and the other system is running 4.1.x. I just wanted to throw this out there to see if anyone knows anything about this. Thanks. AJ --- 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 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- 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
