openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 8:52 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: Updated: (gdb) print *si $4 = {si_be = 0xde8540, si_re = 0xde9960, si_rid = 100, si_bindconf = {sb_uri = {bv_len = 30, bv_val = 0xde1aa0 "ldap://neo-ldap-1.tamu.edu:389"}, sb_tls = 2, sb_method = 128, sb_binddn = {bv_len = 33, bv_val = 0xdd2d98 "uid=zmreplica,cn=admins,cn=zimbra"}, sb_cred = {bv_len = 8, bv_val = 0xde44c0 "9Yew3bqm"}, sb_saslmech = {bv_len = 0, bv_val = 0x0}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x0}, sb_authcId = {bv_len = 0, bv_val = 0x0}, sb_authzId = {bv_len = 0, bv_val = 0x0}}, si_base = {bv_len = 0, bv_val = 0x885c70 ""}, si_logbase = {bv_len = 12, bv_val = 0xde44d0 "cn=accesslog"}, si_filterstr = {bv_len = 15, bv_val = 0xde4510 "(objectclass=*)"}, si_logfilterstr = {bv_len = 46, bv_val = 0xdc6b10 "(&(objectClass=auditWriteObject)(reqResult=0))"}, si_scope = 2, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0xdd2e10, si_exanlist = 0xdd2dc0, si_attrs = 0xdea120, si_exattrs = 0x0, si_allattrs = 0, si_allopattrs = 0, si_schemachecking = 0, si_type = 3, si_ctype = 3, si_interval = 60, si_retryinterval = 0xde4530, si_retrynum_init = 0x885c60, si_retrynum = 0x885c58, si_syncCookie = {ctxcsn = {bv_len = 32, bv_val = 0x24886708 "20080415180631Z#000001#00#000000"}, octet_str = {bv_len = 44, bv_val = 0x23d01a80 "csn=20080415180631Z#000001#00#000000,rid=100"}, rid = 100, sc_next = {stqe_next = 0x0}}, si_manageDSAit = 0, si_slimit = 0, si_tlimit = 0, si_refreshDelete = 0, si_refreshPresent = 0, si_refreshDone = 0, si_syncdata = 1, si_logstate = 0, si_conn_setup = 1, si_msgid = 3, si_presentlist = 0x0, si_ld = 0x24ebc800, si_nonpresentlist = { lh_first = 0x0}, si_mutex = {__data = {__lock = 1, __count = 0, __owner = 19761, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\0001M\000\000\001", '\0' <repeats 26 times>, __align = 1}} -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 8:52 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: > > (gdb) break do_syncrepl > Breakpoint 1 at 0x494cc5: file syncrepl.c, line 1030. > (gdb) cont > Continuing. > [Switching to Thread 1098918208 (LWP 13474)] also: Breakpoint 2, syncrepl_message_to_op (si=0x8cd800, op=0x43805850, msg=0x2547b230) at syncrepl.c:1281 1281 in syncrepl.c (gdb) up #1 0x0000000000493c1e in do_syncrep2 (op=0x43805850, si=0x8cd800) at syncrepl.c:722 722 in syncrepl.c (gdb) print syncCookie $2 = {ctxcsn = {bv_len = 0, bv_val = 0x0}, octet_str = {bv_len = 0, bv_val = 0x0}, rid = 0, sc_next = {stqe_next = 0x0}} --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: (gdb) break do_syncrepl Breakpoint 1 at 0x494cc5: file syncrepl.c, line 1030. (gdb) cont Continuing. [Switching to Thread 1098918208 (LWP 13474)] Breakpoint 1, do_syncrepl (ctx=0x41801e70, arg=0xde9960) at syncrepl.c:1030 1030 syncrepl.c: No such file or directory. in syncrepl.c (gdb) print *si $1 = {si_be = 0xa265d60, si_re = 0x63, si_rid = 1208292709, si_bindconf = {sb_uri = {bv_len = 0, bv_val = 0x43804a20 ""}, sb_tls = 0, sb_method = 0, sb_binddn = {bv_len = 515842056, bv_val = 0x0}, sb_cred = {bv_len = 515842072, bv_val = 0x200000002 <Address 0x200000002 out of bounds>}, sb_saslmech = {bv_len = 18446744073709551615, bv_val = 0xde8614 "ï¿½ï¿½ï¿½ï¿½"}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x1ebf23e0 "ï¿½"}, sb_authcId = {bv_len = 309, bv_val = 0x1ebf2d00 "(&(objectClass=amavisAccount)(|(mail=sentto-11913093-6627-1208292689-evanclark=neo.tamu.edu@returns.groups.yahoo.com)(mail=sentto-11913093-6627-1208292689-evanclark=neo.tamu.edu)(mail=@returns.groups."...}, sb_authzId = {bv_len = 0, bv_val = 0x0}}, si_base = {bv_len = 0, bv_val = 0x0}, si_logbase = {bv_len = 0, bv_val = 0x0}, si_filterstr = { bv_len = 0, bv_val = 0x0}, si_logfilterstr = {bv_len = 0, bv_val = 0xa265dd8 ""}, si_scope = 128, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0x0, si_exanlist = 0x22, si_attrs = 0xa230b68, si_exattrs = 0x22, si_allattrs = 627063816, si_allopattrs = 0, si_schemachecking = 256, si_type = 0, si_ctype = 256, si_interval = 610570800, si_retryinterval = 0x0, si_retrynum_init = 0x43804a00, si_retrynum = 0x0, si_syncCookie = {ctxcsn = {bv_len = 0, bv_val = 0x0}, octet_str = {bv_len = 0, bv_val = 0x0}, rid = 32, sc_next = {stqe_next = 0x8fa0}}, si_manageDSAit = 148281848, si_slimit = 0, si_tlimit = 33, si_refreshDelete = 3, si_refreshPresent = 0, si_refreshDone = 0, si_syncdata = 1132486256, si_logstate = 0, si_conn_setup = 512128712, si_msgid = 0, si_presentlist = 0x619b00, si_ld = 0x3736333d6e6e6f63, si_nonpresentlist = {lh_first = 0x32333d706f203836}, si_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}} -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Friday, April 11, 2008 9:33 PM +0000 quanah(a)zimbra.com wrote: > I have a replica spitting out the following error in its logs (master and > replica running OpenLDAP 2.3.41): This is happening again. With loglevel = sync, I see: Apr 15 13:06:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=A-B-C,ou=people,dc=abc,dc=123,dc=edu (0) Apr 15 13:06:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=XXXXX,ou=people,dc=neo,dc=tamu,dc=edu (0) Apr 15 13:06:36 neo-ldap-3 slapd[13469]: do_syncrep2: rid 100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Apr 15 13:06:36 neo-ldap-3 slapd[13469]: null_callback: error code 0x14 Apr 15 13:06:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu (20) Apr 15 13:06:36 neo-ldap-3 slapd[13469]: do_syncrepl: rid 100 retrying and then it forever more retries: Apr 15 13:07:36 neo-ldap-3 slapd[13469]: null_callback: error code 0x14 Apr 15 13:07:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu (20) Apr 15 13:07:36 neo-ldap-3 slapd[13469]: do_syncrepl: rid 100 retrying On the master, we see: Apr 15 13:06:34 neo-ldap-1 slapd[18587]: conn=313538 op=1 MOD dn="uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu" Apr 15 13:06:34 neo-ldap-1 slapd[18587]: conn=313538 op=1 MOD attr=zimbraPasswordLockoutFailureTime Apr 15 13:06:34 neo-ldap-1 slapd[18587]: conn=313538 op=1 MOD attr=zimbraPasswordLockoutFailureTime Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 fd=24 ACCEPT from IP=10.1.15.23:52299 (IP=10.1.15.21:389) Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=0 STARTTLS Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=0 RESULT oid= err=0 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 fd=24 TLS established tls_ssf=256 ssf=256 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=1 RESULT tag=97 err=0 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=1 RESULT tag=103 err=0 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: Entry reqStart=20080415180532.000001Z,cn=accesslog CSN 20080415180532Z#000000#00#000000 matches ctx 20080415180532Z#000000#00#000000 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=2 SRCH base="uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu" scope=0 deref=3 filter="(objectClass=*)" Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=3 UNBIND Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 fd=23 closed So what I think is of particular interest here, is that the replica hits the master right as the modification has started, but before it has finished. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by hyc＠symas.com 15 Apr '08

15 Apr '08

Howard Chu wrote: > jwm(a)horde.net wrote: >> Full_Name: John Morrissey >> Version: 2.3.41 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.133.190.110) >> >> > OK, the backtraces helped a lot. Thread 6 hit the assertion while trying to > close the connection, and thread 5 was already trying to close the connection. > And Thread 5 was waiting for thread 2 to wake up and give up the connection > handle. Seems like a bug in connection.c, aggravated by the presence of > persistent searches on the connection. Please try the patch in slapd/connection.c 1.416 and report your results, thanks. -- -- 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#5469) Assertion failure causes slapd crash
by hyc＠symas.com 15 Apr '08

15 Apr '08

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: 2.3.41 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.133.190.110) > > OK, the backtraces helped a lot. Thread 6 hit the assertion while trying to close the connection, and thread 5 was already trying to close the connection. And Thread 5 was waiting for thread 2 to wake up and give up the connection handle. Seems like a bug in connection.c, aggravated by the presence of persistent searches on the connection. > (continuing the openldap-software thread starting at > http://marc.info/?l=openldap-software&m=120654684131594&w=2) > > An assertion failure causes slapd to crash every few days in our environment. > The assertion seems to be in servers/slapd/connection.s:680: > > assert( c->c_writewaiter == 0); > -- -- 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#5469) Assertion failure causes slapd crash
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 3:49 PM -0400 John Morrissey <jwm(a)horde.net> wrote: > On Tue, Apr 15, 2008 at 11:12:20AM -0700, Quanah Gibson-Mount wrote: >> --On Tuesday, April 15, 2008 5:33 PM +0000 jwm(a)horde.net wrote: >> > moduleload pw-netscape >> >> What is this? > > http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/passwd/net > scape.c > >> > threads 32 >> >> How many CPUs does your server have? > > Two physical cores, four if you count x86 hyperthread "processors." So two. ;) You could set tool-threads to 2 then, it'd increase slapadds if you ever do them. >> This is a particularly high thread setting. Most often, a lower setting >> results in better performance (I generally use 8 threads on dual-CPU >> systems). Having too many threads has resulted in strange behavior for >> me in the past as well. > > FWIW, slapd has been rock-solid on this hardware with this (or essentially > similar) configuration since before 2.1.30 up through 2.3.30. We skipped > forward to 2.3.41, and started seeing these crashes. However, we weren't > using syncrepl until 2.3.41, either. Yeah, just noting my past experience. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by jwm＠horde.net 15 Apr '08

15 Apr '08

On Tue, Apr 15, 2008 at 11:12:20AM -0700, Quanah Gibson-Mount wrote: > --On Tuesday, April 15, 2008 5:33 PM +0000 jwm(a)horde.net wrote: > > moduleload pw-netscape > > What is this? http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/passwd/netsc… > > threads 32 > > How many CPUs does your server have? Two physical cores, four if you count x86 hyperthread "processors." > This is a particularly high thread setting. Most often, a lower setting > results in better performance (I generally use 8 threads on dual-CPU > systems). Having too many threads has resulted in strange behavior for me > in the past as well. FWIW, slapd has been rock-solid on this hardware with this (or essentially similar) configuration since before 2.1.30 up through 2.3.30. We skipped forward to 2.3.41, and started seeing these crashes. However, we weren't using syncrepl until 2.3.41, either. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5468) You can put irrevant thing on LDIF file "add" line
by hyc＠symas.com 15 Apr '08

15 Apr '08

Thanks for the report. This is a known bug in 2.3 and was fixed in OpenLDAP 2.4.4. The fix will not be backported to 2.3. This ITS will be closed. patrick.ni(a)strangeloopnetworks.com wrote: > Full_Name: Patrick Ni > Version: 2.3.30-5 > OS: Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12etch2) (dannf(a)debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.77.66.100) > > > > Hello, > > I have a group entry for myself "patrick" in the LDAP database as follows: > > dn: cn=patrick,ou=Group,dc=strangeloop,dc=net > objectClass: posixGroup > objectClass: top > cn: patrick > userPassword:: e1NTSEF9eA== > gidNumber: 500 > memberUid: patrick > > > Recently, I realized I could add my 2nd openLDAP account > "dn:uid=patrick2,ou=Accounts,dc=strangeloop,dc=net" into my group "patrick" > using the following LDIF file: > > > ldap1:~/ldap# more group2_patrick.ldif > dn: cn=patrick,ou=Group,dc=strangeloop,dc=net > changetype:modify > add:membership > memberUid:patrick2 > > This should not have succeeded because the "add:membership" line is wrong; It > should have been "add:memberUid". > > thanks > -Patrick > > > -- -- 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#5469) Assertion failure causes slapd crash
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 5:33 PM +0000 jwm(a)horde.net wrote: > moduleload pw-netscape What is this? > threads 32 How many CPUs does your server have? This is a particularly high thread setting. Most often, a lower setting results in better performance (I generally use 8 threads on dual-CPU systems). Having too many threads has resulted in strange behavior for me in the past as well. --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