openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

04 Apr '08

On Thu, 3 Apr 2008, rein(a)basefarm.no wrote: > 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. > > 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. Hm, I hope I have found the race condition that causes this :-) I'm now running with the patch at the end to see if that solves it, only time will tell.. The race is that between the time selecting on the syncrepl socket is enabled by the call to connection_client_enable() and the release of the si_mutex a new message may arrive. If so, the next call to do_syncrepl may fail in its attempt to trylock the mutex and no-one will re-enable selecting on it again. My patch delays enabling of the socket until the mutex has been released, which looks safe to me. Or can the access to si->si_conn without a lock be a problem? Rein Index: OpenLDAP/servers/slapd/syncrepl.c diff -u OpenLDAP/servers/slapd/syncrepl.c:1.9 OpenLDAP/servers/slapd/syncrepl.c:1.10 --- OpenLDAP/servers/slapd/syncrepl.c:1.9 Fri Mar 28 14:25:55 2008 +++ OpenLDAP/servers/slapd/syncrepl.c Fri Apr 4 16:54:05 2008 @@ -1166,6 +1166,7 @@ ber_socket_t s; int i, defer = 1, fail = 0; Backend *be; + int enable_conn = 0; Debug( LDAP_DEBUG_TRACE, "=>do_syncrepl %s\n", si->si_ridtxt, 0, 0 ); @@ -1271,11 +1272,7 @@ * If we failed, tear down the connection and reschedule. */ if ( rc == LDAP_SUCCESS ) { - if ( si->si_conn ) { - connection_client_enable( si->si_conn ); - } else { - si->si_conn = connection_client_setup( s, do_syncrepl, arg ); - } + enable_conn = 1; } else if ( si->si_conn ) { dostop = 1; } @@ -1342,6 +1339,14 @@ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); ldap_pvt_thread_mutex_unlock( &si->si_mutex ); + if ( enable_conn ) { + if ( si->si_conn ) { + connection_client_enable( si->si_conn ); + } else { + si->si_conn = connection_client_setup( s, do_syncrepl, arg ); + } + } + if ( rc ) { if ( fail == RETRYNUM_TAIL ) { Debug( LDAP_DEBUG_ANY,

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by h.b.furuseth＠usit.uio.no 04 Apr '08

04 Apr '08

Since it crashes on if ( so->s_op->o_connid == op->o_connid && so->s_op->o_msgid == op->orn_msgid ) please try frame 0 print *op print *so->s_op and maybe backtrace full while you are at it. -- Hallvard

1 0

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

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