openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Ron Lamarche 22 Jun '17

22 Jun '17

Hi. My company has decided to migrate from Oracle Directory Server 7.0 (ODSEE ) to OpenLDAP due to end of life supportability issues . I've installed the RHEL 6.9 OpenLDAP bundled product and have a working suffix based on cn=config vs. slapd.conf model but cannot get the accesslog overlays/DB's to work properly (ldapsearch returns accesslog records but never completes and instead hangs showing "ldap_int_select" . Need to ctl -c to exit ) Here's the details: - more /etc/redhat-release o Red Hat Enterprise Linux Server release 6.9 (Santiago) - yum list installed | grep openldap o compat-openldap.x86_64 1:2.3.43-2.el6 o openldap.x86_64 2.4.40-16.el6 o openldap-clients.x86_64 2.4.40-16.el6 o openldap-devel.x86_64 2.4.40-16.el6 o openldap-servers.x86_64 2.4.40-16.el6 - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={2}bdb,cn=config" | egrep "olcRo|olcSu" < - -------- main suffix DB o olcSuffix: dc=mydomain,dc=ca o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcRootPW: {SSHA}ZODaH7MZuRjuG+FTzIZvdPg5edL2WDjg - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={3}bdb,cn=config" < - ---accesslog DB and overlay o dn: olcDatabase={3}bdb,cn=config o objectClass: olcDatabaseConfig o objectClass: olcBdbConfig o olcDatabase: {3}bdb o olcDbDirectory: /var/lib/ldap/accesslog o olcSuffix: cn=accesslog o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcDbIndex: default eq o olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart - o dn: olcOverlay={0}accesslog,olcDatabase={3}bdb,cn=config o objectClass: olcOverlayConfig o objectClass: olcAccessLogConfig o olcOverlay: {0}accesslog o olcAccessLogDB: cn=accesslog o olcAccessLogOps: writes reads session o olcAccessLogPurge: 07+00:00 01+00:00 o olcAccessLogSuccess: TRUE - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "cn=module{0},cn=config" |< - --------------loaded modules o dn: cn=module{0},cn=config o objectClass: olcModuleList o cn: module{0} o olcModulePath: /usr/lib64/openldap o olcModuleLoad: {0}syncprov.la o olcModuleLoad: {1}accesslog.la When I execute the ldapsearch on cn=accesslog I get the following ( ctl-c needed to exit from the hang ) : ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mailposte,dc=ca" -b cn=accesslog -W ldap_url_parse_ext(ldap://) ldap_initialize( ldap://:389/??base ) ldap_create ldap_url_parse_ext(ldap://:389/??base) Enter LDAP Password: ... stuff omitted due to length ... reqDN: reqStart=20170620210816.000003Z,cn=accesslog ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqResult: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqMod: objectClass:+ auditSearch reqMod: structuralObjectClass:+ auditSearch reqMod: reqStart:+ 20170620210816.000003Z reqMod: reqEnd:+ 20170620210816.000004Z reqMod: reqType:+ search reqMod: reqSession:+ 18446744073709551615 reqMod: reqAuthzID:+ cn=dev13,dc=mailposte,dc=ca reqMod: reqDN:+ cn=accesslog reqMod: reqResult:+ 0 reqMod: reqScope:+ one reqMod: reqDerefAliases:+ never reqMod: reqAttrsOnly:+ TRUE reqMod: reqFilter:+ (reqStart<=20170613210816Z) reqMod: reqAttr:+ 1.1 reqMod: reqEntries:+ 0 reqMod: reqTimeLimit:+ -1 reqMod: reqSizeLimit:+ -1 reqMod: entryUUID:+ 52bef5ee-ea48-1036-9807-2fa6ad6fded4 reqMod: creatorsName:+ cn=dev13,dc=mailposte,dc=ca reqMod: createTimestamp:+ 20170620210816Z reqMod: entryCSN:+ 20170620210816.416676Z#000000#000#000000 reqMod: modifiersName:+ cn=dev13,dc=mailposte,dc=ca reqMod: modifyTimestamp:+ 20170620210816Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4 ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x14c91c0 msgid -1 wait4msg ld 0x14c91c0 msgid -1 (infinite timeout) wait4msg continue ld 0x14c91c0 msgid -1 all 0 ** ld 0x14c91c0 Connections: * host: (null) port: 389 (default) refcnt: 2 status: Connected last used: Wed Jun 21 13:46:58 2017 ** ld 0x14c91c0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x14c91c0 request count 1 (abandoned 0) ** ld 0x14c91c0 Response Queue: Empty ld 0x14c91c0 response count 0 ldap_chkResponseList ld 0x14c91c0 msgid -1 all 0 ldap_chkResponseList returns ld 0x14c91c0 NULL ldap_int_select ^C When I do an strace of the working suffix ( dc=mydomain,dc=ca ) I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b dc=mydomain,dc=ca -w my_passwd ..... stuff omitted due to length .... write(3, "0\5\2\1\3B\0", 7) = 7 shutdown(3, SHUT_RDWR) = 0 close(3) = 0 write(2, "ldap_free_connection: actually f"..., 37ldap_free_connection: actually freed ) = 37 exit_group(0) = ? +++ exited with 0 +++ When I do an strace of cn=accesslog I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b cn=accesslog -w my_passwd ..... stuff omitted due to length .... write(1, "reqEntryUUID: 52bef5ee-ea48-1036"..., 51reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4) = 51 write(2, "ldap_get_attribute_ber\n", 23ldap_get_attribute_ber) = 23 write(2, "ldap_msgfree\n", 13ldap_msgfree) = 13 write(2, "ldap_result ld 0x24381e0 msgid -"..., 34ldap_result ld 0x24381e0 msgid -1) = 34 write(2, "wait4msg ld 0x24381e0 msgid -1 ("..., 50wait4msg ld 0x24381e0 msgid -1 (infinite timeout)) = 50 write(2, "wait4msg continue ld 0x24381e0 m"..., 46wait4msg continue ld 0x24381e0 msgid -1 all 0) = 46 write(2, "** ld 0x24381e0 Connections:\n", 29** ld 0x24381e0 Connections:) = 29 write(2, "* host: (null) port: 389 (defa"..., 37* host: (null) port: 389 (default)) = 37 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected) = 31 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3477, ...}) = 0 write(2, " last used: Wed Jun 21 14:07:30"..., 39 last used: Wed Jun 21 14:07:30 2017) = 39 write(2, "\n", 1) = 1 write(2, "** ld 0x24381e0 Outstanding Requ"..., 38** ld 0x24381e0 Outstanding Requests:) = 38 write(2, " * msgid 2, origid 2, status In"..., 41 * msgid 2, origid 2, status InProgress) = 41 write(2, " outstanding referrals 0, pare"..., 43 outstanding referrals 0, parent count 0) = 43 write(2, " ld 0x24381e0 request count 1 ("..., 45 ld 0x24381e0 request count 1 (abandoned 0)) = 45 write(2, "** ld 0x24381e0 Response Queue:\n", 32** ld 0x24381e0 Response Queue:) = 32 write(2, " Empty\n", 9 Empty) = 9 write(2, " ld 0x24381e0 response count 0\n", 32 ld 0x24381e0 response count 0) = 32 write(2, "ldap_chkResponseList ld 0x24381e"..., 49ldap_chkResponseList ld 0x24381e0 msgid -1 all 0) = 49 write(2, "ldap_chkResponseList returns ld "..., 47ldap_chkResponseList returns ld 0x24381e0 NULL) = 47 write(2, "ldap_int_select\n", 16ldap_int_select) = 16 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1 < - ------------------------------- This means poll is waiting for something on this File descriptor which never gets returned ^C Process 7844 detached <detached ...> Here is the ldif file used for moduleload by ldapadd : cat addModule.ldif dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap #olcModuleLoad: {0}back_bdb olcModuleLoad: syncprov.la olcModuleLoad: accesslog.la Here is the ldif file to add the accesslog db and overlay by ldapadd: cat addAccesslog2DB # Accesslog database definitions dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {3}bdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=dev13,dc=mydomain,dc=ca olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes reads session olcAccessLogSuccess: TRUE # scan the accesslog DB every day and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00 I have also created /var/lib/ldap/accesslog owned by ldap:ldap : ls -l /var/lib/ldap/accesslog total 11232 -rw-r-----. 1 ldap ldap 4096 Jun 20 17:08 alock -rw-------. 1 ldap ldap 24576 Jun 20 17:08 __db.001 -rw-------. 1 ldap ldap 188416 Jun 21 14:07 __db.002 -rw-------. 1 ldap ldap 270336 Jun 21 13:46 __db.003 -rw-------. 1 ldap ldap 98304 Jun 21 13:46 __db.004 -rw-------. 1 ldap ldap 753664 Jun 21 14:07 __db.005 -rw-------. 1 ldap ldap 32768 Jun 21 14:07 __db.006 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 dn2id.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 entryCSN.bdb -rw-------. 1 ldap ldap 32768 Jun 20 17:08 id2entry.bdb -rw-------. 1 ldap ldap 10485760 Jun 20 17:08 log.0000000001 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 objectClass.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqEnd.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqResult.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqStart.bdb I am new to this forum so If I've missed something please let me know. Constructive comments and suggestions are greatly appreciated. regards RON LAMARCHE Technical Specialist, Online Channel Innovapost

1 0

Re: Limit which database is reachable on which port (slapd is listening on)?
by Howard Chu 22 Jun '17

22 Jun '17

Karsten Heymann wrote: > Hi, > > short question: If I configure slapd to listen to several ports and > have several databases configured, is there a way to limit which > database is visible on which port? I want to use a single slapd > instance to serve multiple databases (slapd-meta instances to be > exact) and for each database want to use a dedicated listening port, > somehow like port-based virtual hosts in the apache web server. The > reason is that I want to define different firewall rules for the > different databases. Is this possible with openldap? Read the slapd.access(5) manpage, use an ACL specifying sockname=xxx for the local port identifier. > Best regards > Karsten > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 7

syncrepl fails after upgrade to openldap 2.4.45
by Juergen.Sprenger＠swisscom.com 22 Jun '17

22 Jun '17

Hi, after upgrading from openldap-2.4.44-r1 to openldap-2.4.45 on my Gentoo machine multi-master-replication does not work anymore. Has anything changed in configuration options for syncrepl or are certificates treated differently now? In the logs I found the following message: Jun 22 10:33:13 ids00000 slapd[30734]: [ID 000001 (local4.debug)] slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) Running slapd in foreground with -d -1 revealed this message: TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 594b8120 slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) My syncrepl configuriation: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** I have verified the certificate and my selfsigned ca-certificate with openssl, and both are ok: # openssl verify /etc/ssl/certs/dannatuCA-cacert.pem /etc/ssl/certs/dannatuCA-cacert.pem: OK # openssl verify /etc/ssl/openldap/dannatu.ch.pem /etc/ssl/openldap/dannatu.ch.pem: OK Also verification with openssl s_client seems ok: # openssl s_client -connect ldap.dannatu.ch:636 -tls1_2 CONNECTED(00000003) depth=1 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = Dannatu AG CA, emailAddress = admin(a)dannatu.ch verify return:1 depth=0 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = dannatu.ch, emailAddress = admin(a)dannatu.ch verify return:1 --- Certificate chain 0 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=dannatu.ch/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch 1 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch --- After downgrading to openldap-2.4.44-r1 everything worked fine again. Seems certificate handling has changed. Any hints? Juergen Sprenger

1 0

Delete the root entry of a DIT (mdb as backend)
by Hongfu Huang 21 Jun '17

21 Jun '17

Hi all, I have defined a DIT (LMDB) as follows: > dn: olcDatabase={3}mdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {3}mdb > olcDbDirectory: /var/lib/ldap/mycompany/o=mycompany > olcSuffix: o=mycompany > olcRootDN: uid=admin,ou=system > olcAccess: {0}to attrs=userPassword,shadowLastChange by > dn="uid=admin,ou=system" write by anonymous auth by self write by * none > olcAccess: {1}to * by dn="uid=admin,ou=system" write by * none > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbEnvFlags: writemap > olcDbEnvFlags: nometasync > olcDbNoSync: FALSE > olcDbIndex: objectClass pres,eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: uidNumber pres,eq > olcDbIndex: gidNumber pres,eq > olcDbIndex: mail pres,eq,sub > olcDbIndex: ou pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: loginShell pres,eq > olcDbIndex: memberUid pres,eq,sub > olcDbIndex: nisMapName pres,eq,sub > olcDbIndex: nisMapEntry pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 4294967296 > olcDbMode: 0600 > olcDbSearchStack: 16 I can add the root entry as: > dn: o=mycompany > objectClass: organization > objectClass: top > o: mycompany And I can also add and delete sub-entries under o=mycompany. But I can not delete the root entry o=mycompany, even there is no sub-entry below it. Please no that the rootdn (uid=admin,ou=system) is not under the subffix (o=mycompany), that is why no rootPW is defined for this DIT. The rootDN and rootPW are defined in the second DIT (in BDB) The weird thing was that I could search and found it: > ldapsearch -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 -b o=mycompany > # extended LDIF > # > # LDAPv3 > # base <o=cornerbank> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # mycompany > dn: o=mycompany > o: mycompany > objectClass: organization > objectClass: top > > # search result > search: 2 > result: 0 Success But it would fail if I tried to delete it: > $ ldapdelete -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 o=mycompany > ldap_delete: No such object (32) > 32 In the other words, I could import the whole DIT for o=mycompany, but could not delete the whole DIT (the root entry o=mycompany could not be deleted). Does somebody know how to solve this problem? Thanks! Regards -- Hongfu Huang, Senior System Integrator M.Sc. Computer Science AdNovum Informatik AG Roentgenstrasse 22, 8005 Zurich, Switzerland phone +41 44 272 6111, direct +41 44 270 5266 hongfu.huang(a)adnovum.ch, www.adnovum.ch Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore

2 1

Error: Can't contact LDAP server
by Jelle de Jong 19 Jun '17

19 Jun '17

Hello everybody, # my /etc/ldap/slapd.conf http://paste.debian.net/plainh/076816e3 I am trying to debug an issue for a while and I can use some help. During midday or in the morning there seems to be something happening that is causing smbd (samba) to not be able to connect to the ldap server. Since the machine is localhost is powerfull enough and has free cpu and memory I am wondering what is going on. Maybe there is some connection maximum but these are the only messages I am getting. Does somebody know how to debug this, or know the options to tweak to get rid of the messages? Kind regards, Jelle de Jong Jun 15 12:39:29 stayce smbd[9632]: [2017/06/15 12:39:29.549569, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:39:29 stayce smbd[9632]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:39:29 stayce smbd[9632]: #011(unknown) Jun 15 12:39:59 stayce smbd[5683]: [2017/06/15 12:39:59.076347, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:39:59 stayce smbd[5683]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:39:59 stayce smbd[5683]: #011(unknown) Jun 15 12:40:14 stayce smbd[5685]: [2017/06/15 12:40:14.190979, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:14 stayce smbd[5685]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:14 stayce smbd[5685]: #011(unknown) Jun 15 12:40:14 stayce smbd[5686]: [2017/06/15 12:40:14.232185, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:14 stayce smbd[5686]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:14 stayce smbd[5686]: #011(unknown) Jun 15 12:40:17 stayce smbd[5783]: [2017/06/15 12:40:17.852955, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:17 stayce smbd[5783]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:17 stayce smbd[5783]: #011(unknown) Jun 15 12:40:29 stayce smbd[5787]: [2017/06/15 12:40:29.636496, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:29 stayce smbd[5787]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:29 stayce smbd[5787]: #011(unknown)

2 1

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 19 Jun '17

19 Jun '17

opensource(a)gmx-topmail.de wrote: >> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. > > I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. > > One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. If you meant libc.so yeah, you can't do that. LMDB uses process-shared POSIX mutexes in shared memory. glibc has a fundamental (and unfixable) flaw; it doesn't guarantee compatibility for the internal structure of pthread_mutex_t types between library versions. You cannot safely mix glibc versions among multiple programs concurrently accessing the same LMDB environment. Some details on the glibc issue here https://sourceware.org/bugzilla/show_bug.cgi?id=21119 It affects other libraries like BerkeleyDB too https://bugzilla.redhat.com/show_bug.cgi?id=1394862 -- -- 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

Limit which database is reachable on which port (slapd is listening on)?
by Karsten Heymann 19 Jun '17

19 Jun '17

Hi, short question: If I configure slapd to listen to several ports and have several databases configured, is there a way to limit which database is visible on which port? I want to use a single slapd instance to serve multiple databases (slapd-meta instances to be exact) and for each database want to use a dedicated listening port, somehow like port-based virtual hosts in the apache web server. The reason is that I want to define different firewall rules for the different databases. Is this possible with openldap? Best regards Karsten

1 0

RE: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by opensource＠gmx-topmail.de 18 Jun '17

18 Jun '17

> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. *Shrug.*

1 0

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 18 Jun '17

18 Jun '17

opensource(a)gmx-topmail.de wrote: > We are using LMDB and are running a big number of tests on a CI server (Debian via Docker, Xenon CPU). Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > The crash happens during opening the database. This is done a lot in the tests without problems (and on Windows this problem does not exist). However, during the CI process we get the crash quite reproducible (~80% crash rate when running the full CI test suite). > > This is our basic code triggering the SIGSEGV (minus error checking for simplicity): > > mdb_env_create(&dbEnv_); > mdb_env_set_maxdbs(dbEnv_, 8); > mdb_env_set_mapsize(dbEnv_, maxDbSizeInKByte * 1024); > mdb_env_open(dbEnv_, directory, 0, fileMode); > MDB_txn* txn; > mdb_txn_begin(dbEnv_, NULL, 0, &txn); > > It crashes inside mdb_txn_begin with this: > SIGSEGV (0xb) at pc=0x00007fd2607e4b58, pid=23603, tid=0x00007fd228633700 > C [libpthread.so.0+0x5b58] __pthread_mutex_lock_full+0x1a8 > > I digged into it a bit, and could tracd it down to this LOCK_MUTEX call in mdb_txn_renew0: > > /* Not yet touching txn == env->me_txn0, it may be active */ > if (ti) { > if (LOCK_MUTEX(rc, env, env->me_wmutex)) > return rc; > > I also logged some data about the env and the mutex (which looks normal however): > PID: 23603 ENV: 0x7fd1e03e9ab0 > TXN: 0x7fd22811b000 COUNT: 0 KIND: 144 LOCK: 0 OWNER: 0 > > Any idea what could go wrong here? > > Thanks! > Markus > > > Some additional crash info: > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd22801a058 > > Registers: > RAX=0x00007fd22801a060, RBX=0x00007fd22811b040, RCX=0x0000000000000000, RDX=0x0000000000000000 > RSP=0x00007fd22862ff50, RBP=0x0000000000005c4f, RSI=0x0000000000000080, RDI=0x0000000000005c4f > R8 =0x0000000000000080, R9 =0x0000000000000000, R10=0x00007fd22811b060, R11=0x0000000000000000 > R12=0x0000000000000000, R13=0x00007fd22813b0f0, R14=0x00007fd2286309d0, R15=0x00007fd25848b000 > RIP=0x00007fd2607e4b58, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Top of Stack: (sp=0x00007fd22862ff50) > 0x00007fd22862ff50: 00007fd22813b0f0 00007fd228630040 > 0x00007fd22862ff60: 0000000000000000 00007fd22813b0f0 > 0x00007fd22862ff70: 00007fd2286309d0 00007fd20c2d05e4 > 0x00007fd22862ff80: 00007fd228630050 00007fd22862ff90 > 0x00007fd22862ff90: 0000000000001020 000000000000003c > 0x00007fd22862ffa0: 0000000a00000023 0000000a00000000 > 0x00007fd22862ffb0: 00007fd228633700 00007fd25fee1c29 > 0x00007fd22862ffc0: 0000000000000000 00007fd25fe7a423 > 0x00007fd22862ffd0: 00007fd2286309d0 0000000900000000 > 0x00007fd22862ffe0: 0000000000000008 00007fd244000000 > 0x00007fd22862fff0: 00007fd22813b0f0 00007fd25fe79ae3 > 0x00007fd228630000: 0000000000000000 00000000286300c0 > 0x00007fd228630010: 0000000000000000 00007fd25fe7b255 > 0x00007fd228630020: 00007fd22811b000 00007fd1e03e9ab0 > 0x00007fd228630030: 00007fd1e08f3260 00007fd25fe6fb22 > 0x00007fd228630040: 00007fd2286300c0 00007fd20c2d0e8a > 0x00007fd228630050: 00007fd2286300c0 00007fd2601ac2a0 > 0x00007fd228630060: 0000000000000020 00007fd244000000 > 0x00007fd228630070: 0000000800000000 00007fd25fe79ae3 > 0x00007fd228630080: 0000000000000020 00007fd228630660 > 0x00007fd228630090: 00007fd1e08f3260 00007fd2286301c8 > 0x00007fd2286300a0: 00000000601ac2a0 0000000000000000 > 0x00007fd2286300b0: 00007fd1e03e9ab0 00007fd25fe6fb22 > 0x00007fd2286300c0: 00007fd228630660 00007fd20c23a768 > 0x00007fd2286300d0: 0000000200f01b00 00007fd20000003b > 0x00007fd2286300e0: 00007fd20c2eb3fd 00007fd24921da4c > 0x00007fd2286300f0: 00000005cac01420 00007fd22814c210 > 0x00007fd228630100: 00007fd228630460 00007fd24921f99f > 0x00007fd228630110: 00007fd2286301c8 0000002000000000 > 0x00007fd228630120: 0000000000000000 0000000000000000 > 0x00007fd228630130: 0000000000000000 0000000000000020 > 0x00007fd228630140: 0000000000000000 0000000000000000 > > Instructions: (pc=0x00007fd2607e4b58) > 0x00007fd2607e4b38: 00 a9 00 00 00 40 0f 85 02 ff ff ff c7 43 04 01 > 0x00007fd2607e4b48: 00 00 00 64 48 8b 04 25 e0 02 00 00 48 83 e0 fe > 0x00007fd2607e4b58: 4c 89 50 f8 64 48 8b 04 25 e0 02 00 00 48 89 43 > 0x00007fd2607e4b68: 20 64 48 8b 04 25 10 00 00 00 48 05 e0 02 00 00 > > Register to memory mapping: > > RAX=0x00007fd22801a060 is an unknown value > RBX=0x00007fd22811b040 is an unknown value > RCX=0x0000000000000000 is an unknown value > RDX=0x0000000000000000 is an unknown value > RSP=0x00007fd22862ff50 is pointing into the stack for thread: 0x00007fd25848b000 > RBP=0x0000000000005c4f is an unknown value > RSI=0x0000000000000080 is an unknown value > RDI=0x0000000000005c4f is an unknown value > R8 =0x0000000000000080 is an unknown value > R9 =0x0000000000000000 is an unknown value > R10=0x00007fd22811b060 is an unknown value > R11=0x0000000000000000 is an unknown value > R12=0x0000000000000000 is an unknown value > R13={method} {0x00007fd22813b0f0} 'nativeCreate' '(Ljava/lang/String;J[B)J' in 'MyDb' > R14=0x00007fd2286309d0 is pointing into the stack for thread: 0x00007fd25848b000 > R15=0x00007fd25848b000 is a thread > > > > -- -- 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

Elliptic Curve support in 2.4 branch
by Abdelkader Chelouah 18 Jun '17

18 Jun '17

Elliptic Curve support for OpenSSL was added in master branch 4 years ago (ITS#7595). Is there any plan to backport EC support for OpenSSL in 2.4 branch ?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical