openldap-bugs

openldap-bugs@openldap.org

1 participants
21005 discussions

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 04 Apr '08

04 Apr '08

On Fri, 4 Apr 2008, Howard Chu wrote: > rein(a)basefarm.no wrote: >> So far it looks to me as if the syncrepl thread has managed to return >> without >> adding the connection socket back to slap_daemon.sd_readers. But whether >> that >> is correct or not, and how it has managed to do it if so, I cannot tell. > > Since you're working with HEAD ... Were there any write operations on > cn=config just before the hang? (Thinking it may be connected to the > SYNC_PAUSED handling at line 1303, except any subsequent request would wake > up the listener anyway.) No, the config backend isn't even configured into the server. I have also tried without the auditlog just to make sure that wasn't involved, but it happend anyhow. We have also added a linux server on one of the sites to see if the problem is related to solaris. So far it hasn't stopped receiving updates, but is has only run since last evening so it is far too early to conclude anything. Rein

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 04 Apr '08

04 Apr '08

rein(a)basefarm.no wrote: > So far it looks to me as if the syncrepl thread has managed to return without > adding the connection socket back to slap_daemon.sd_readers. But whether that > is correct or not, and how it has managed to do it if so, I cannot tell. Since you're working with HEAD ... Were there any write operations on cn=config just before the hang? (Thinking it may be connected to the SYNC_PAUSED handling at line 1303, except any subsequent request would wake up the listener anyway.) > Any pointers as to what can be wrong are highly appreciated. I have a core file > from a server that has stopped receiving if there is anything I should look for > there. > > Rein Tollevik > Basefarm AS > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5444) slapd seg. fault using mulitmirrored mode
by ando＠sys-net.it 03 Apr '08

03 Apr '08

hyc(a)symas.com wrote: > OK, I've reproduced the crash and patched it in HEAD, and added a consumer > write to the test050 script. Please test. Works for me. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Thursday, April 03, 2008 6:41 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u > zimbra -h ldap://'. also: (gdb) print so $1 = (syncops *) 0x12392240 (gdb) print *so $2 = {s_next = 0x12393510, s_base = {bv_len = 12, bv_val = 0x1238dd50 "cn=accesslog"}, s_eid = 1, s_op = 0x11d8fc00, s_rid = 100, s_filterstr = {bv_len = 0, bv_val = 0x0}, s_flags = 1, s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_qtask = 0x0, s_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} from frame 0. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by hyc＠symas.com 03 Apr '08

03 Apr '08

quanah(a)zimbra.com wrote: > --On Tuesday, April 01, 2008 6:24 PM +0000 > sahullameerbasha.nagore(a)etrade.com wrote: > >> Full_Name: ameer basha >> Version: 2.4.8 >> OS: Red Hat linux As3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.93.33.254) >> >> >> I am getting the following error while adding the data into the ldap >> through siteminder gui. >> >> slapd: schema_init.c:2215: integerIndexer: Assertion `i> 0' failed. >> >> Do you have any idea why this error is getting > > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474161> > > may also be related to this bug report. It includes reproduction data, > although the assert in this case triggered on the stringIndexer. Thanks for the data, that helped. Fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 03 Apr '08

03 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: solaris8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Our persistent syncrepl consumers stops receiving data after a while, with no indication of why :-( They don't recognize restarts of the producer, so the only way to get the replication running again is to restart the consumers. The consumers have a single bdb backend database that is replicated from the producer, and uses the auditlog overlay on this backend. There are 4 of them, running in pairs as load-balanced search servers on two sites. The two servers in each pair are identical configured, and they are all running 64bit solaris8 if that matters. There are two master servers, one on each site, with a more complicated configuration. They replicate subordinate backend datebases between each other, the consumers replicate the glue suffix of these backends. These servers are running linux in 32- and 64bit mode, and I have not seen the same type of replication stops between these master servers. Using netstat it shows that the send queue is full on the producer side, and the receive window is empty on the consumer, which to me looks as if the consumer has stopped reading from the provider. I have used a debugger to look at the servers after they have stopped receiving, and the syncrepl task is sitting at the end of slapd_rq.task_list, with next_sched.tv_sec==0 (which mean it will not be scheduled normally?) The syncrepl is configured with "retry=60 +". The si_conn of the syncinfo_t looks normal, and its c_sd socket is on slap_daemon.sd_actives fd_set, but not on sd_readers nor sd_writers. And none of the threads are running any syncrepl code. Looking at "slapd -d sync" output and the auditlogs it seem to stop receiving in the middle of a burst of updates (although that could be a coinsident). The other slave in the pairs continues to receive updates, so I assume this is a consumer side problem. So far it looks to me as if the syncrepl thread has managed to return without adding the connection socket back to slap_daemon.sd_readers. But whether that is correct or not, and how it has managed to do it if so, I cannot tell. Any pointers as to what can be wrong are highly appreciated. I have a core file from a server that has stopped receiving if there is anything I should look for there. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5453) slapd binding error at startup
by hyc＠symas.com 03 Apr '08

03 Apr '08

m_hannini(a)yahoo.com wrote: > Full_Name: Mohammed > Version: 2.3.37 > OS: AIX 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.146.102.46) > > > Hi, > I installed openldap 2.3.37 on AIX 5.3. When I start slapd, I get this error: > daemon: bind(7) failed errno=67 (Address already in use) > slapd starting > > This is even though there is nothing running on port 389 but the ldap server > itself. > # netstat -an |grep 389 > tcp4 0 0 *.389 *.* LISTEN > > > Any ideas? There is no indication of a bug in OpenLDAP software here. This ITS will be closed. Software usage questions should be directed to the openldap-software mailing list. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Tuesday, April 01, 2008 6:24 PM +0000 sahullameerbasha.nagore(a)etrade.com wrote: > Full_Name: ameer basha > Version: 2.4.8 > OS: Red Hat linux As3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.93.33.254) > > > I am getting the following error while adding the data into the ldap > through siteminder gui. > > slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed. > > Do you have any idea why this error is getting <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474161> may also be related to this bug report. It includes reproduction data, although the assert in this case triggered on the stringIndexer. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5453) slapd binding error at startup
by m_hannini＠yahoo.com 03 Apr '08

03 Apr '08

Full_Name: Mohammed Version: 2.3.37 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.146.102.46) Hi, I installed openldap 2.3.37 on AIX 5.3. When I start slapd, I get this error: daemon: bind(7) failed errno=67 (Address already in use) slapd starting This is even though there is nothing running on port 389 but the ldap server itself. # netstat -an |grep 389 tcp4 0 0 *.389 *.* LISTEN Any ideas? Thanks

1 0

(ITS#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://'. Program terminated with signal 11, Segmentation fault. #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) bt #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 #1 0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50, which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640 #2 0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50, which=op_abandon) at backover.c:702 #3 0x000000000049bca7 in over_op_abandon (op=0x42002b40, rs=0x42002a50) at backover.c:760 #4 0x0000000000450729 in fe_op_abandon (op=0x42002b40, rs=0x42002a50) at abandon.c:115 #5 0x000000000042b249 in connection_abandon (c=0x12603dd0) at connection.c:792 #6 0x000000000042b41c in connection_closing (c=0x12603dd0, why=0x4be9a0 "connection lost") at connection.c:840 #7 0x000000000042ca0f in connection_read (s=38, cri=0x42002d90) at connection.c:1457 #8 0x000000000042c1f8 in connection_read_thread (ctx=0x42002e10, argv=0x26) at connection.c:1254 #9 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x88ce10) at tpool.c:478 #10 0x0000003342606137 in ?? () #11 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) l 1021 syncops *so, *soprev; 1022 1023 ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); 1024 for ( so=si->si_ops, soprev = (syncops *)&si->si_ops; so; 1025 soprev=so, so=so->s_next ) { 1026 if ( so->s_op->o_connid == op->o_connid && 1027 so->s_op->o_msgid == op->orn_msgid ) { 1028 so->s_op->o_abandon = 1; 1029 soprev->s_next = so->s_next; 1030 break; (gdb)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs