openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#7638) Handle connection loss in SQL backend
by pierre＠reactos.org 07 Jul '13

07 Jul '13

Full_Name: Pierre Schweitzer Version: HEAD OS: Ubuntu URL: http://fc.isima.fr/~schweitz/schweitz/0001-In-the-SQL-backend-add-code-to-h… Submission from: (NULL) (90.27.237.49) Hi, here is a patch to handle a possible connection loss to DBMS for the SQL backend. Right now, in case of connection loss, slapd just denied any entry lookup with an error 80 (backend error). With this patch, before preparing any req on the given connection handle, the backend will first try to check whether the connection is active by issue a dummy query. In case it's not, it will close the previous connection and open a new one. And then, will prepare the req on the connection link. I made this choice of developement because, preparing statement, executing it and then, only looking whether it fails to re-submit would have been more complex, since it would have required to start over the whole process for the query (statement preparation and such) while preparation & execution aren't not in the same function. This patch has been tested and validated in production on the ReactOS Foundation infrastructure. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Pierre Schweitzer (pierre(a)reactos.org). I have not assigned rights and/or interest in this work to any party. I, Pierre Schweitzer, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Regards, Pierre

1 0

Re: (ITS#7637) Need documentation: LDAP on virtual IP address
by hyc＠symas.com 04 Jul '13

04 Jul '13

Ulrich.Windl(a)rz.uni-regensburg.de wrote: > Full_Name: Ulrich Windl > Version: 2.4.26 > OS: Linux (SLES11 SP2) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.199.152.129) > > > I was able to set up a master LDAP server and a replication consumer using the > physical host names and TLS. However when I tried to bind slapd on a virtual IP > address ("interface alias"), I never got slapd working (even though I fixed the > certificates for TLS, of course). Dynamic configuration ("cn=config") seems to > make things very difficult, because slapd ends in a state where _nobody_ can > make configuration changes. Use the openldap-technical mailing list to ask for configuration help. You talk about IP addresses and yet in your quoted text below you are using hostnames. Be consistent when you post your question to the mailing list otherwise no one will understand what you're asking for. Closing this ITS. > It seems slapd tried to use the wrong URI (using the physical host where nobody > is listening): > slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error, > ldap_start_tls failed (-1) > slapd[10036]: do_syncrepl: rid=002 rc -1 retrying > > slapd is listening on ldap://vhost.domain.org/ however. > > I read lots of procedures using Google, but could not find the solution for this > problem. Thus I suggest to add documentation how to configure such a scenario: > > 1) Set up an LDAP Master server that provides service on a specific IP address > using TLS > 2) Set up a replication consumer that provides service on a specific IP address > using TLS also > 3) The replication consumer should use the address where the master server > listens for replication > > It sounds like an every-day setup, but I failed multiple times, thus the request > for documentation. > > -- -- 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#7637) Need documentation: LDAP on virtual IP address
by Ulrich.Windl＠rz.uni-regensburg.de 04 Jul '13

04 Jul '13

Full_Name: Ulrich Windl Version: 2.4.26 OS: Linux (SLES11 SP2) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.152.129) I was able to set up a master LDAP server and a replication consumer using the physical host names and TLS. However when I tried to bind slapd on a virtual IP address ("interface alias"), I never got slapd working (even though I fixed the certificates for TLS, of course). Dynamic configuration ("cn=config") seems to make things very difficult, because slapd ends in a state where _nobody_ can make configuration changes. It seems slapd tried to use the wrong URI (using the physical host where nobody is listening): slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error, ldap_start_tls failed (-1) slapd[10036]: do_syncrepl: rid=002 rc -1 retrying slapd is listening on ldap://vhost.domain.org/ however. I read lots of procedures using Google, but could not find the solution for this problem. Thus I suggest to add documentation how to configure such a scenario: 1) Set up an LDAP Master server that provides service on a specific IP address using TLS 2) Set up a replication consumer that provides service on a specific IP address using TLS also 3) The replication consumer should use the address where the master server listens for replication It sounds like an every-day setup, but I failed multiple times, thus the request for documentation.

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 03 Jul '13

03 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: >> kb9vqf(a)pearsoncomputing.net wrote: >>> Full_Name: Timothy Pearson >>> Version: 2.4.31 >>> OS: Debian Wheezy >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (131.156.2.26) >>> >>> >>> The setup: >>> Multi-master syncrepl on two servers >>> Identical hardware and software between servers >>> Self-signed TLS using common (private) CA certificate >>> >>> The problem: >>> slapd on one server crashes repeatably within a minute of slapd > starting on the >>> other server. slapd works reliably if and only if the other server is not >>> running a slapd process. >> >> 1) 2.4.31 is ancient. Current is 2.4.35. Please provide a backtrace > against a >> current OpenLDAP release. >> >> 2) Your backtrace shows a crash in a slapi plugin. If the bug is in your > plugin there's nothing we can do about it. >> >> 3) Don't touch the individual files inside the slapd configuration > database. >> Use "slapcat -n0". > > Thank you for your prompt response. In the backtrace I posted, which > portion suggests that the crash occurred in a plugin? I would have > expected to see at least one frame in something other than > ../../../../servers/slapd. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe356c700 (LWP 10433)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe3569f60, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe3569fd0, rs=0x7fffe3569f60) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 The slapi_* functions would not be present in the stack trace unless you had configured a slapi plugin on this database. -- -- 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#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 03 Jul '13

03 Jul '13

> kb9vqf(a)pearsoncomputing.net wrote: >> Full_Name: Timothy Pearson >> Version: 2.4.31 >> OS: Debian Wheezy >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.156.2.26) >> >> >> The setup: >> Multi-master syncrepl on two servers >> Identical hardware and software between servers >> Self-signed TLS using common (private) CA certificate >> >> The problem: >> slapd on one server crashes repeatably within a minute of slapd starting on the >> other server. slapd works reliably if and only if the other server is not >> running a slapd process. > > 1) 2.4.31 is ancient. Current is 2.4.35. Please provide a backtrace against a > current OpenLDAP release. > > 2) Your backtrace shows a crash in a slapi plugin. If the bug is in your plugin there's nothing we can do about it. > > 3) Don't touch the individual files inside the slapd configuration database. > Use "slapcat -n0". Thank you for your prompt response. In the backtrace I posted, which portion suggests that the crash occurred in a plugin? I would have expected to see at least one frame in something other than ../../../../servers/slapd. I am not directly modifying the config database text files, but did not know the correct method to dump the existing files. Thanks for the command!

1 0

Re: (ITS#7633) Slapd hangs on hdb write lock
by hyc＠symas.com 03 Jul '13

03 Jul '13

dusan.fric(a)t-systems.sk wrote: > --_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Hi guys, > > good news, the issue is solved. We changed db setting (DB_CONFIG) as follow= > s: > > set_lk_detect DB_LOCK_RANDOM > > (instead of bad set_lk_detect DB_LOCK_EXPIRE) > > and no hangs until now. That's great, but why was it set to DB_LOCK_EXPIRE in the first place? DB_LOCK_RANDOM is the default, you should not be changing this setting without a good reason and good knowledge of what you're doing. > > We can also find the same issue described here > > http://www.openldap.org/lists/openldap-technical/201102/msg00074.html > > > FYI - customer's test confirmed it. > > Thanks for your suggestions and help. > > Regards, > Dusan -- -- 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#7633) Slapd hangs on hdb write lock
by dusan.fric＠t-systems.sk 03 Jul '13

03 Jul '13

--_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, good news, the issue is solved. We changed db setting (DB_CONFIG) as follow= s: set_lk_detect DB_LOCK_RANDOM (instead of bad set_lk_detect DB_LOCK_EXPIRE) and no hangs until now. We can also find the same issue described here http://www.openldap.org/lists/openldap-technical/201102/msg00074.html FYI - customer's test confirmed it. Thanks for your suggestions and help. Regards, Dusan --_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style></style></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1>Hi guys,<o:p></o= :p><o:p> </o:p>good = news, the issue is solved. We changed db setting (DB_CONFIG) as follows:<o:= p></o:p><o:p> </o:p>= set_lk_detect DB_LOCK_RANDOM<o:p></o:p><o:p> = </o:p>(instead of bad <s>set_lk_detect DB_LOCK_EXP= IRE</s>)<o:p></o:p><o:p> </o:p>and no hangs until now. <o:p></o:p><o= :p> </o:p>We can also find the same issue des= cribed here<o:p></o:p><o:p> </o:p><a href=3D"http://www.openldap.org/lists/openldap-technical/2= 01102/msg00074.html">http://www.openldap.org/lists/openldap-technical/20110= 2/msg00074.html</a><o:p></o:p><o:p> </o:p></p= ><o:p> </o:p>FYI –= customer’s test confirmed it.<o:p></o:p><o:= p> </o:p>Thanks for your suggestions and help= .<o:p></o:p><o:p> </o:p>Regards,<o:p></o:p>Dusan<o:p></o:p></div><= /body></html>= --_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_--

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 02 Jul '13

02 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: > Full_Name: Timothy Pearson > Version: 2.4.31 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.156.2.26) > > > The setup: > Multi-master syncrepl on two servers > Identical hardware and software between servers > Self-signed TLS using common (private) CA certificate > > The problem: > slapd on one server crashes repeatably within a minute of slapd starting on the > other server. slapd works reliably if and only if the other server is not > running a slapd process. 1) 2.4.31 is ancient. Current is 2.4.35. Please provide a backtrace against a current OpenLDAP release. 2) Your backtrace shows a crash in a slapi plugin. If the bug is in your plugin there's nothing we can do about it. 3) Don't touch the individual files inside the slapd configuration database. Use "slapcat -n0". > > Backtrace (does not change appreciably from crash to crash): > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe356c700 (LWP 10433)] > 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 > #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, > fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 > #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 > "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 > #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe3569fd0, > rs=<optimized out>, prc=<optimized out>) at > ../../../../../servers/slapd/slapi/slapi_overlay.c:313 > #5 slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, > prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 > #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe3569f60, op=<optimized out>) > at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 > #7 slapi_op_func (op=0x7fffe3569fd0, rs=0x7fffe3569f60) at > ../../../../../servers/slapd/slapi/slapi_overlay.c:556 > #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe3569fd0, > rs=0x7fffe3569f60, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at > ../../../../servers/slapd/backover.c:661 > #9 0x00005555555ff31b in over_op_func (op=0x7fffe3569fd0, rs=<optimized out>, > which=<optimized out>) at ../../../../servers/slapd/backover.c:723 > #10 0x00007ffff1c4870e in syncprov_findbase (op=op@entry=0x555555dd8560, > fc=fc@entry=0x7fffe356a280) at > ../../../../../servers/slapd/overlays/syncprov.c:453 > #11 0x00007ffff1c4b1ef in syncprov_op_search (op=0x555555dd8560, > rs=0x7fffe356ba50) at ../../../../../servers/slapd/overlays/syncprov.c:2465 > #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, > rs=rs@entry=0x7fffe356ba50, which=which@entry=op_search, oi=0x5555559e57f0, > on=0x5555559e15e0) at ../../../../servers/slapd/backover.c:661 > #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe356ba50, op=<optimized out>) > at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 > #14 slapi_op_func (op=0x555555dd8560, rs=0x7fffe356ba50) at > ../../../../../servers/slapd/slapi/slapi_overlay.c:556 > #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, > rs=0x7fffe356ba50, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at > ../../../../servers/slapd/backover.c:661 > #16 0x00005555555ff31b in over_op_func (op=0x555555dd8560, rs=<optimized out>, > which=<optimized out>) at ../../../../servers/slapd/backover.c:723 > #17 0x0000555555594641 in fe_op_search (op=0x555555dd8560, rs=0x7fffe356ba50) at > ../../../../servers/slapd/search.c:402 > #18 0x0000555555593f06 in do_search (op=0x555555dd8560, rs=0x7fffe356ba50) at > ../../../../servers/slapd/search.c:247 > #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe356bba0, > arg_v=arg_v@entry=0x555555dd8560) at > ../../../../servers/slapd/connection.c:1150 > #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe356bba0, > argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 > #21 0x00007ffff7b9dff3 in ?? () from > /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 > #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at > pthread_create.c:304 > #23 0x00007ffff5adaa7d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #24 0x0000000000000000 in ?? () > > > Relevant configuration files: > > > olcDatabase={0}config.ldif: > > dn: olcDatabase={0}config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: {0}to * by > group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" > write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write > by dn.base="cn=admin,dc=<redacted>" write by sockurl.regex="^ldapi:///$" write > by dynacl/aci write by * none > olcAddContentAcl: TRUE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=config > olcRootPW:: REDACTED > olcSyncUseSubentry: FALSE > olcMonitoring: FALSE > structuralObjectClass: olcDatabaseConfig > creatorsName: cn=config > createTimestamp: 20130702170316Z > olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ > binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" > searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 > tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem"lcSyncrepl: > {1}rid=002 provider=ldaps://ldap003.<redacted>/ binddn="cn=admin,dc=<redacted>" > bindmethod=simple credentials="ldapadmin001" searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 tls_reqcert=never > tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" > olcMirrorMode: TRUE > entryCSN: 20130702180604.682031Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702180604Z > > > olcDatabase={1}hdb.ldif: > > dn: olcDatabase={1}hdb > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {1}hdb > olcDbDirectory: /var/lib/ldap > olcSuffix: dc=<redacted> > olcAccess: {0}to attrs=userPassword,shadowLastChange,krb5Key,krb5PrincipalName,krb5KeyVersionNumber,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,privateRootCertificateKey > by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" > write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" by > sockurl.regex="^ldapi:///$" write by anonymous auth by self write by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to * by > group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" > write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write > by sockurl.regex="^ldapi:///$" write by dynacl/aci write > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=admin,dc=<redacted> > olcRootPW:: REDACTED > olcMonitoring: TRUE > olcDbCacheSize: 1000 > olcDbCheckpoint: 512 30 > olcDbConfig: {0}set_cachesize 0 67108864 1 > olcDbConfig: {1}set_lg_regionmax 262144 > olcDbConfig: {2}set_lg_bsize 2097152 > olcDbNoSync: FALSE > olcDbDirtyRead: FALSE > olcDbIDLcacheSize: 0 > olcDbIndex: objectClass eq > olcDbIndex: krb5PrincipalName eq,pres > olcDbIndex: cn eq,pres,subinitial > olcDbIndex: mail eq,pres > olcDbIndex: uid pres,eq > olcDbIndex: uidNumber eq > olcDbIndex: gidNumber eq > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > olcPlugin: postoperation /opt/trinity/lib/slapi-acl-manager.so plugin_init > admingroup-dn:=cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted> > realm:=CEET.NIU.EDU aclfile:=/etc/heimdal-kdc/kadmind.acl builtinadmin:=admin > structuralObjectClass: olcHdbConfig > creatorsName: cn=config > createTimestamp: 20130702170316Z > olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ > binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" > searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 > tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" > olcSyncrepl: {1}rid=002 provider=ldaps://ldap003.<redacted>/ > binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" > searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 > tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" > olcMirrorMode: TRUE > entryCSN: 20130702170511.039863Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702170511Z > > > olcDatabase={0}config/olcOverlay={0}syncprov.ldif: > > dn: olcOverlay={0}syncprov > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: {0}syncprov > structuralObjectClass: olcSyncProvConfig > entryUUID: 14f25934-7785-1032-93bd-0fe5d581c3b6 > creatorsName: > createTimestamp: 20130702170337Z > entryCSN: 20130702170337.631532Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702170337Z > > > olcDatabase={1}hdb/olcOverlay={0}syncprov.ldif: > > dn: olcOverlay={0}syncprov > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: {0}syncprov > structuralObjectClass: olcSyncProvConfig > entryUUID: bfa2e530-778d-1032-9b41-e7480f731418 > creatorsName: > createTimestamp: 20130702180539Z > entryCSN: 20130702180539.975057Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702180539Z > > -- -- 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#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 02 Jul '13

02 Jul '13

Since my report above seems to have been somewhat mangled by the submission process, here is a link to a plain-text version of the same report: http://www.ceet.niu.edu/pastebin/openldap_bug_report_7636.txt

1 0

(ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 02 Jul '13

02 Jul '13

Full_Name: Timothy Pearson Version: 2.4.31 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.156.2.26) The setup: Multi-master syncrepl on two servers Identical hardware and software between servers Self-signed TLS using common (private) CA certificate The problem: slapd on one server crashes repeatably within a minute of slapd starting on the other server. slapd works reliably if and only if the other server is not running a slapd process. Backtrace (does not change appreciably from crash to crash): Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe356c700 (LWP 10433)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe3569f60, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe3569fd0, rs=0x7fffe3569f60) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe3569fd0, rs=0x7fffe3569f60, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at ../../../../servers/slapd/backover.c:661 #9 0x00005555555ff31b in over_op_func (op=0x7fffe3569fd0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff1c4870e in syncprov_findbase (op=op@entry=0x555555dd8560, fc=fc@entry=0x7fffe356a280) at ../../../../../servers/slapd/overlays/syncprov.c:453 #11 0x00007ffff1c4b1ef in syncprov_op_search (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../../servers/slapd/overlays/syncprov.c:2465 #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, rs=rs@entry=0x7fffe356ba50, which=which@entry=op_search, oi=0x5555559e57f0, on=0x5555559e15e0) at ../../../../servers/slapd/backover.c:661 #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe356ba50, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 #14 slapi_op_func (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, rs=0x7fffe356ba50, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at ../../../../servers/slapd/backover.c:661 #16 0x00005555555ff31b in over_op_func (op=0x555555dd8560, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #17 0x0000555555594641 in fe_op_search (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../servers/slapd/search.c:402 #18 0x0000555555593f06 in do_search (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../servers/slapd/search.c:247 #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe356bba0, arg_v=arg_v@entry=0x555555dd8560) at ../../../../servers/slapd/connection.c:1150 #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe356bba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21 0x00007ffff7b9dff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007ffff5adaa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x0000000000000000 in ?? () Relevant configuration files: olcDatabase={0}config.ldif: dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write by dn.base="cn=admin,dc=<redacted>" write by sockurl.regex="^ldapi:///$" write by dynacl/aci write by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW:: REDACTED olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig creatorsName: cn=config createTimestamp: 20130702170316Z olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem"lcSyncrepl: {1}rid=002 provider=ldaps://ldap003.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" olcMirrorMode: TRUE entryCSN: 20130702180604.682031Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702180604Z olcDatabase={1}hdb.ldif: dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=<redacted> olcAccess: {0}to attrs=userPassword,shadowLastChange,krb5Key,krb5PrincipalName,krb5KeyVersionNumber,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,privateRootCertificateKey by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" by sockurl.regex="^ldapi:///$" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write by sockurl.regex="^ldapi:///$" write by dynacl/aci write olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=<redacted> olcRootPW:: REDACTED olcMonitoring: TRUE olcDbCacheSize: 1000 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 67108864 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: krb5PrincipalName eq,pres olcDbIndex: cn eq,pres,subinitial olcDbIndex: mail eq,pres olcDbIndex: uid pres,eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 olcPlugin: postoperation /opt/trinity/lib/slapi-acl-manager.so plugin_init admingroup-dn:=cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted> realm:=CEET.NIU.EDU aclfile:=/etc/heimdal-kdc/kadmind.acl builtinadmin:=admin structuralObjectClass: olcHdbConfig creatorsName: cn=config createTimestamp: 20130702170316Z olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" olcSyncrepl: {1}rid=002 provider=ldaps://ldap003.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" olcMirrorMode: TRUE entryCSN: 20130702170511.039863Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702170511Z olcDatabase={0}config/olcOverlay={0}syncprov.ldif: dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 14f25934-7785-1032-93bd-0fe5d581c3b6 creatorsName: createTimestamp: 20130702170337Z entryCSN: 20130702170337.631532Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702170337Z olcDatabase={1}hdb/olcOverlay={0}syncprov.ldif: dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: bfa2e530-778d-1032-9b41-e7480f731418 creatorsName: createTimestamp: 20130702180539Z entryCSN: 20130702180539.975057Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702180539Z

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