- openldap-bugs - openldap.org

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 14 Dec '09

14 Dec '09

--On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: >># 0=C2=A0 0x000000000066f891 in ?? () >> (gdb) > > So where's the thr apply all bt command inside gdb? You've just loaded Please provide the backtrace as noted if you want this to be further investigated. Thanks! Again, after you run: gdb </slapd> <core> You then need to run: thr apply all bt To get a backtrace of all threads, and then submit that to the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 13 Dec '09

13 Dec '09

Now it is OK. Build was successful and slapd is working fine. No more delays on start of TLS/SSL queries. Thanks Pavel

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 12 Dec '09

12 Dec '09

--On Saturday, December 12, 2009 1:16 PM +0330 afshin afzali=20 <a.afzali2003(a)gmail.com> wrote: > Hi, > It is makes no difference except that the 'Bus error' replaced with > 'Segmentation fault'. Also I've used the 'make clean' to cleanup my > installation. Any suggestion ? > > Regards, > =C2=A0 > > > [root@dc1 libexec]# gdb --core=3Dcore.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law.=C2=A0 Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] ># 0=C2=A0 0x000000000066f891 in ?? () > (gdb) So where's the thr apply all bt command inside gdb? You've just loaded the = core, you haven't asked for any information. Also, keep replies to the bug tracker (i.e., CC it as well) if you want=20 help. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 11 Dec '09

11 Dec '09

--On Friday, December 11, 2009 9:22 PM +0000 pali(a)tmapy.cz wrote: > > --=-NIKZplg5L6FNssI2Xw1S > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > It has worked (in 2.4.18, 2.4.19, 2.4.20) with the same configs. Please re-sync RE24. There was missed commit sync'd in tonight. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by hyc＠symas.com 11 Dec '09

11 Dec '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Thread 1 (Thread 20774): > OK. The patch for #6419 that was backported from HEAD needs some additional > stuff that isn't yet in RE24. > Fixed now in RE24, closing this ITS. -- -- 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#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by hyc＠symas.com 11 Dec '09

11 Dec '09

michael(a)stroeder.com wrote: > Thread 1 (Thread 20774): > #0 0x00002ad97f0974e5 in raise () from /lib64/libc.so.6 > #1 0x00002ad97f0989b0 in abort () from /lib64/libc.so.6 > #2 0x00002ad97f09024a in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000429e29 in slap_cf_aux_table_unparse (src=0x7f3120, > bv=0x7fffc98185f0, tab0=<value optimized out>) at config.c:1447 > #4 0x000000000048885d in syncrepl_unparse (si=0x7f30f0, bv=0x7fffc9818650) at > syncrepl.c:4582 > #5 0x000000000048e1bb in syncrepl_config (c=<value optimized out>) at > syncrepl.c:4748 > #6 0x000000000042ad06 in config_get_vals (cf=0x724240, c=0x5126) at config.c:443 > #7 0x0000000000422c43 in config_build_attrs (e=<value optimized out>, > at=0x7ba628, ad=0x7a31d0, ct=0x724240, c=0x7fffc9818830) at bconfig.c:6033 > #8 0x0000000000423014 in config_build_entry (op=<value optimized out>, > rs=<value optimized out>, parent=<value optimized out>, > c=0x7fffc9818830, rdn=0x7fffc981a110, main=0x724860, extra=0x2ad98199d7a0) > at bconfig.c:6139 > #9 0x0000000000427261 in config_back_db_open (be=<value optimized out>, > cr=<value optimized out>) at bconfig.c:6527 > #10 0x0000000000441949 in backend_startup_one (be=0x7bc400, cr=0x7fffc981a180) > at backend.c:224 > #11 0x0000000000441c2b in backend_startup (be=0x7bc400) at backend.c:325 > #12 0x000000000041ae46 in main (argc=8, argv=0x7fffc981a488) at main.c:947 OK. The patch for #6419 that was backported from HEAD needs some additional stuff that isn't yet in RE24. -- -- 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#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by michael＠stroeder.com 11 Dec '09

11 Dec '09

Thread 1 (Thread 20774): #0 0x00002ad97f0974e5 in raise () from /lib64/libc.so.6 #1 0x00002ad97f0989b0 in abort () from /lib64/libc.so.6 #2 0x00002ad97f09024a in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000429e29 in slap_cf_aux_table_unparse (src=0x7f3120, bv=0x7fffc98185f0, tab0=<value optimized out>) at config.c:1447 #4 0x000000000048885d in syncrepl_unparse (si=0x7f30f0, bv=0x7fffc9818650) at syncrepl.c:4582 #5 0x000000000048e1bb in syncrepl_config (c=<value optimized out>) at syncrepl.c:4748 #6 0x000000000042ad06 in config_get_vals (cf=0x724240, c=0x5126) at config.c:443 #7 0x0000000000422c43 in config_build_attrs (e=<value optimized out>, at=0x7ba628, ad=0x7a31d0, ct=0x724240, c=0x7fffc9818830) at bconfig.c:6033 #8 0x0000000000423014 in config_build_entry (op=<value optimized out>, rs=<value optimized out>, parent=<value optimized out>, c=0x7fffc9818830, rdn=0x7fffc981a110, main=0x724860, extra=0x2ad98199d7a0) at bconfig.c:6139 #9 0x0000000000427261 in config_back_db_open (be=<value optimized out>, cr=<value optimized out>) at bconfig.c:6527 #10 0x0000000000441949 in backend_startup_one (be=0x7bc400, cr=0x7fffc981a180) at backend.c:224 #11 0x0000000000441c2b in backend_startup (be=0x7bc400) at backend.c:325 #12 0x000000000041ae46 in main (argc=8, argv=0x7fffc981a488) at main.c:947

1 0

(ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by michael＠stroeder.com 11 Dec '09

11 Dec '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.120.34) >>>>> Starting test017-syncreplication-refresh for bdb... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9012... ./scripts/test017-syncreplication-refresh: line 86: 20774 Aborted (core dumped) $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 Using ldapsearch to check that consumer slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test017-syncreplication-refresh: line 102: kill: (20774) - No such process >>>>> ./scripts/test017-syncreplication-refresh failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 11 Dec '09

11 Dec '09

--=-NIKZplg5L6FNssI2Xw1S Content-Type: text/plain Content-Transfer-Encoding: 7bit It has worked (in 2.4.18, 2.4.19, 2.4.20) with the same configs. Pavel --=-NIKZplg5L6FNssI2Xw1S Content-Disposition: attachment; filename="slapd.conf" Content-Type: text/plain; name="slapd.conf"; charset="UTF-8" Content-Transfer-Encoding: 7bit # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap24/schema/corba.schema include /etc/openldap24/schema/core.schema include /etc/openldap24/schema/cosine.schema include /etc/openldap24/schema/duaconf.schema include /etc/openldap24/schema/dyngroup.schema include /etc/openldap24/schema/inetorgperson.schema include /etc/openldap24/schema/java.schema include /etc/openldap24/schema/misc.schema include /etc/openldap24/schema/nis.schema include /etc/openldap24/schema/openldap.schema include /etc/openldap24/schema/ppolicy.schema include /etc/openldap24/schema/collective.schema include /etc/openldap24/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap24/slapd.pid argsfile /var/run/openldap24/slapd.args # Load dynamic backend modules: # modulepath /usr/lib/openldap24 # or /usr/lib64/openldap24 # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCACertificateFile /etc/pki/tls/cacert.pem # TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateFile /etc/pki/tls/certs/ldap3.ldapnet.tmapy.cz-cert.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap3.ldapnet.tmapy.cz-key.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # Define global ACLs to disable default read access and provide default # behaviour for samba/pam use include /etc/openldap24/slapd.access.conf # Provide write access to replicators, and cover access to any other # attributes (default anonymous read access may be undesirable) access to dn.subtree="dc=tmapy,dc=cz" by group="cn=Replicator,ou=Group,dc=tmapy,dc=cz" write by users read by anonymous read # loglevel <integer> # Specify the level at which debugging statements and # operation statistics should be syslogged (currently # 1 trace function calls # 2 debug packet handling # 4 heavy trace debugging # 8 connection management # 16 print out packets sent and received # 32 search filter processing # 64 configuration file processing # 128 access control list processing # 256 stats log # connections/operations/results # 512 stats log entries sent # 1024 print communication with shell # backends # 2048 entry parsing # 1 + 2 + 8 + 16 + 32 + 64 + 128 + 256 # loglevel 507 # 16 + 256 # loglevel 272 # 8 + 16 + 128 + 256 # loglevel 408 # 16 + 128 + 256 # loglevel 400 # 2 + 8 + 64 + 256 # loglevel 330 # 8 + 128 # loglevel 136 # 128 + 256 # loglevel 384 # loglevel 128 loglevel 0 ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=tmapy,dc=cz" checkpoint 1024 15 rootdn "cn=Manager,dc=tmapy,dc=cz" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret rootpw heslo # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap24/tmapy.cz # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN,entryUUID eq # Replicas of this database #replogfile /var/lib/ldap24/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # # enable monitoring # database monitor # # # allow onlu rootdn to read the monitor # access to * # by dn.exact="cn=Manager,dc=tmapy,dc=cz" read # by * none # syncrepl directives ServerID 11 syncrepl rid=001 provider=ldap://ldap1.ldapnet.tmapy.cz:389 starttls=yes bindmethod=simple binddn="cn=Manager,dc=tmapy,dc=cz" credentials=heslo searchbase="dc=tmapy,dc=cz" schemachecking=on type=refreshAndPersist retry="5 5 300 5" timeout=1 --=-NIKZplg5L6FNssI2Xw1S Content-Disposition: attachment; filename="slapd.access.conf" Content-Type: text/plain; name="slapd.access.conf"; charset="UTF-8" Content-Transfer-Encoding: 7bit # This configuration file contains default ACLs that attempt to cater # to most setups, specifically unix authentication, samba-s ldapsam backend # and allowing users to have a shared address book # If these ACLs don-t meet your needs, please do not modify the file in-place, # but rather make a copy, and change the include directive in slapd.conf # This file is *not* marked as noreplace, so it will be replaced during an # upgrade, this is done so that we can ensure that the ACLs are in sync with # the schema files they require. # The root DIT should be accessible to all clients access to dn.exact="" by * read # So should the schema access to dn.subtree="cn=Subschema" by * read # Generic ACLs # These ACLs should work well for any domain-based (ie dc=,dc=) suffix, # but need adjustment and testing for any other suffix # Note that these ACLs allow anonymous read access to most non-password # attributes, you may want to prevent leakage of this information by # removing the "by anonymous read" lines # Regex-based ACLs also impose a performance penalty, replace # for example dn.regex="^([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" with # dn.subtree="ou=People,dc=example,dc=com" and all $2-s with dc=example,dc=com # if you need the extra performance # Protect passwords, using a regex so we can have generic accounts with # write access # Openldap will not authenticate against non-userPassword attributes # but we would have to duplicate most rules ... access to dn.regex="^([^,]*,)?ou=[^,]+,(dc=[^,]+(,dc=[^,]+)*)$" attrs=sambaLMPassword,sambaNTPassword,userPassword,sambaPasswordHistory,sambaPwdLastSet,shadowLastChange,shadowMax by self write by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by anonymous auth by * none # ACL allowing samba domain controllers to write their domain info access to dn.regex="^sambaDomainName=([^,]+),(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,sambaDomain,uidNumber,gidNumber by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # ACL allowing samba domain controllers to add user accounts access to dn.regex="^([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixAccount,sambaSamAccount by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # allow users to modify their own "address book" entries: access to dn.regex="([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" attrs=inetOrgPerson,mail by self write by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba domain controllers to create groups and group mappings access to dn.regex="^([^,]+,)?ou=Group,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixGroup,sambaGroupMapping by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba domain controllers to create machine accounts access to dn.regex="^([^,]+,)?ou=Hosts,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixAccount,inetOrgperson,sambaSamAccount by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba to create idmap entries access to dn.regex="^([^,]+,)?ou=Idmap,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,sambaIdmapEntry by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow users in the domain to add entries to the "global address book": # For use with Evolution, the attrs list could be modified to be: # attrs=children,entry,inetOrgPerson,evolutionperson,calEntry # if evolutionperson.schema and calendar.schema are available access to dn.regex="^([^,]+,)?ou=Contacts,(dc=[^,]+(,dc=[^,]+)*)$" attrs=children,entry,inetOrgPerson by dn.sub,expand="ou=People,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read --=-NIKZplg5L6FNssI2Xw1S--

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 11 Dec '09

11 Dec '09

--On Friday, December 11, 2009 4:05 PM +0000 pali(a)tmapy.cz wrote: > How can I download this particular revision? > > I'm not familiar with CVS > > I've found this: > http://www.openldap.org/software/repo.html#AnonCVS > > I've tried this > > CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP" > cvs login > cvs -z3 checkout -P -rOPENLDAP_REL_ENG_2_4 ldap > > but after build I cannot start it, it is crashing > > [root@ldap3 ~]# slaptest24 -f /etc/openldap24/slapd.conf -F /tmp/test > -d1 Please supply your configuration file that is causing slapd to assert. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6429) New mirror
by mirror＠artfiles.org 11 Dec '09

11 Dec '09

Full_Name: Artfiles New Media GmbH Version: OS: URL: Submission from: (NULL) (80.252.98.63) Hello, here are the facts about our mirror: * URL of mirror: http://artfiles.org/openldap.org * Hosting institution, country and city where the mirror is located: Artfiles New Media GmbH, Hamburg, Germany * Contact email address: mirror(a)artfiles.org * Update frequency: daily With best regards Artfiles New Media GmbH Andreas Worbs

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 11 Dec '09

11 Dec '09

How can I download this particular revision? I'm not familiar with CVS I've found this: http://www.openldap.org/software/repo.html#AnonCVS I've tried this CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP" cvs login cvs -z3 checkout -P -rOPENLDAP_REL_ENG_2_4 ldap but after build I cannot start it, it is crashing [root@ldap3 ~]# slaptest24 -f /etc/openldap24/slapd.conf -F /tmp/test -d1 finishes with this: oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 config_build_entry: "olcDatabase={1}bdb" slaptest24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Aborted or with LANG=cs_CZ.UTF-8 oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 config_build_entry: "olcDatabase={1}bdb" slaptest24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Neúspěšně ukončen (SIGABRT) similar is slapd [root@ldap3 ~]# slapd24 -f /etc/openldap24/slapd.conf -d 1 slapd24 startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}corba" config_build_entry: "cn={1}core" config_build_entry: "cn={2}cosine" config_build_entry: "cn={3}duaconf" config_build_entry: "cn={4}dyngroup" config_build_entry: "cn={5}inetorgperson" config_build_entry: "cn={6}java" config_build_entry: "cn={7}misc" config_build_entry: "cn={8}nis" config_build_entry: "cn={9}openldap" config_build_entry: "cn={10}ppolicy" config_build_entry: "cn={11}collective" config_build_entry: "cn={12}samba" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" slapd24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Neúspěšně ukončen (SIGABRT) I don't use cn=config, I have only slapd.conf. Is it the reason? Pavel

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 11 Dec '09

11 Dec '09

On Thu, Dec 10, 2009 at 08:21:20AM -0800, Quanah Gibson-Mount wrote: >Well, now 2.4.20 is current (just to note). Right. I'm now running this version. The results below are with 2.4.20, and not 2.4.19. >What we'll need for resolving your issue is: > >(a) Your configuration files (minus passwords) # egrep -v '^#|^$' etc/openldap/slapd.conf TLSCertificateFile <removed>.crt TLSCertificateKeyFile <removed>.key TLSCACertificateFile <removed>.ca include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/nis.schema include /usr/local/ldap/etc/openldap/schema/qmail.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema include /usr/local/ldap/etc/openldap/schema/mod_vhost_ldap.schema include /usr/local/ldap/etc/openldap/schema/monsternett_vhost_ldap.schema include /usr/local/ldap/etc/openldap/schema/sql_user.schema include /usr/local/ldap/etc/openldap/schema/using_space.schema pidfile /usr/local/ldap/var/run/slapd/slapd.pid argsfile /usr/local/ldap/var/run/slapd/slapd.args loglevel stats modulepath /usr/local/ldap/lib moduleload back_hdb sizelimit 99999 tool-threads 8 threads 16 concurrency 32 backend hdb database hdb suffix "dc=<removed>" directory "/usr/local/ldap/var/openldap-data" cachesize 60000 dbconfig set_cachesize 0 52428800 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectclass,sn eq index cn,uniqueMember,memberUid,uidNumber,gidNumber pres,eq index uid,mail,associatedDomain,mailAlternateAddress,apacheServerName,apacheServerAlias,apacheSuexecUid pres,eq,sub lastmod on checkpoint 512 30 access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=<removed>" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=<removed>" write by * read >(b) A backtrace from gdb of a crash. Since this is a *live* server, I don't want to run it through gdb if I don't have to. Also, the server doesn't really crash, it just hangs, using 100% of one CPU core. We currently have a script that checks if ldapsearch succeeds, and if not, it restarts slapd. AFAIK, if we would have done this via gdb directly, the ports would still be open, and slapd wouldn't be able to start, which means I would have to sit there for an hour to quickly be able to run a backtrace, so slapd could be restarted instantly :) Anyway, instead, I made it dump a core (by sending killall -11 slapd in my script). I hope this is sufficient. --- gdb core bt start --- (gdb) thread apply all bt Thread 18 (process 7691): #0 0x00007ff212f77b78 in epoll_wait () from /lib/libc.so.6 #1 0x000000000041c618 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2465 #2 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007ff212f775ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 17 (process 7692): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x410f6670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x2732490, rs=0x41277ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x2732490, rs=0x41277ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x2732490, rs=0x41277ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x2732490, rs=0x41277ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x41277df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x41277df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 16 (process 7694): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x418f7670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x285ba50, rs=0x41a78ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x285ba50, rs=0x41a78ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x285ba50, rs=0x41a78ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x285ba50, rs=0x41a78ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x41a78df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x41a78df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 15 (process 7695): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x42947670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1e40163b0, rs=0x42ac8ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x42ac8df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x42ac8df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 14 (process 7699): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x43148670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42babf0, rs=0x432c9ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x432c9df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x432c9df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 13 (process 7700): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x43949670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x16e57b0, rs=0x43acaca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x16e57b0, rs=0x43acaca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x16e57b0, rs=0x43acaca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x16e57b0, rs=0x43acaca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x43acadf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x43acadf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 12 (process 7715): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4414a670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e7260, rs=0x442cbca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x442cbdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x442cbdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 11 (process 7864): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4494b670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x1b731b0, rs=0x44accca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x1b731b0, rs=0x44accca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x1b731b0, rs=0x44accca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x1b731b0, rs=0x44accca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x44accdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x44accdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 10 (process 8395): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4514c670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1e4038380, rs=0x452cdca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x452cddf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x452cddf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 9 (process 8808): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4594d670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1fcac89e0, rs=0x45aceca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x45acedf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x45acedf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 8 (process 9706): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4614e670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414b4d0, rs=0x462cfca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414b4d0, rs=0x462cfca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414b4d0, rs=0x462cfca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414b4d0, rs=0x462cfca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x462cfdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x462cfdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 7 (process 10771): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4694f670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414c100, rs=0x46ad0ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414c100, rs=0x46ad0ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414c100, rs=0x46ad0ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414c100, rs=0x46ad0ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x46ad0df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x46ad0df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 6 (process 11742): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x47150670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e8640, rs=0x472d1ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x472d1df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x472d1df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 5 (process 11743): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x47951670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414c610, rs=0x47ad2ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414c610, rs=0x47ad2ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414c610, rs=0x47ad2ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414c610, rs=0x47ad2ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x47ad2df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x47ad2df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 4 (process 18180): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x48152670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x4376ee0, rs=0x482d3ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x482d3df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x482d3df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 3 (process 18190): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x48953670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42d4510, rs=0x48ad4ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x48ad4df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x48ad4df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (process 18200): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x49154670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e78e0, rs=0x492d5ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x492d5df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x492d5df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 1 (process 7690): #0 0x00007ff214c50715 in pthread_join () from /lib/libpthread.so.0 #1 0x0000000000419c4c in slapd_daemon () at daemon.c:2840 #2 0x0000000000407d8a in main (argc=7, argv=0x7fff1d3caa88) at main.c:961 --- gdb core bt end --- I guess the last part in the treads are caused by me sending a SIGSEGV, i.e. every thread was inside clone () after slapd started hanging? Well, I'll leave the analysis to the experts I think :-) -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 3:13 PM +0000 pavel.lisy(a)tmapy.cz wrote: > Today I've tried go back to 2.4.18 release and in the same configuration > there isn't this bug. > > So it is problem in 2.4.19 and 2.4.20. Please try CVS RE24, there's a fix to TLS in there that may be the cause. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 1:02 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi Quanah > > I did reconfigure with --enable-debug, but just could get this: To build with debugging symbols, you need to use a CFLAGS value of -g, like: CFLAGS="-g" ./configure <whatever options you use> make depend make make install DESTDIR=/my/path/to/install STRIP="" The STRIP="" ensures none of the debugging symbols inserted by gcc get stripped out. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 10:44 AM +0100 Helge Milde <helge(a)monsternett.no> wrote: > I have now installed openldap 2.4.19 from source (default configuration > except for --enable-crypt=yes). > ># slapd -V > @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ > > But unfortunately, the bug is still there. Nothing has changed at all.. > It has crashed 10 times since I did the migration 10 hours ago. It > usually crashes 1-2 times at night, and 10-20 times during work hours > (when the servers have more load). Well, now 2.4.20 is current (just to note). What we'll need for resolving your issue is: (a) Your configuration files (minus passwords) (b) A backtrace from gdb of a crash. Make sure you build OpenLDAP with debugging symbols (using CFLAGS of -g) and when you run make install, make sure you use STRIP="", like: make install DESTDIR=/my/path/to/install STRIP="" Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pavel.lisy＠tmapy.cz 10 Dec '09

10 Dec '09

Today I've tried go back to 2.4.18 release and in the same configuration there isn't this bug. So it is problem in 2.4.19 and 2.4.20. Pavel

1 0

(ITS#6428) modification to global limits require a restart to take effect
by rhafer＠suse.de 10 Dec '09

10 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.231.132) Changes to the global limits in "olcDatabase=frontend,cn=config" don't take effect database until slapd is restarted. I am working on a fix.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 10 Dec '09

10 Dec '09

I have now installed openldap 2.4.19 from source (default configuration except for --enable-crypt=yes). # slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ But unfortunately, the bug is still there. Nothing has changed at all.. It has crashed 10 times since I did the migration 10 hours ago. It usually crashes 1-2 times at night, and 10-20 times during work hours (when the servers have more load). When I migrated, I recreated the database by typing: # oldbin/slapcat > db.ldif # newbin/slapadd < db.ldif # (under the new openldap/slapd user) So I can't imagine the database can be corrupt in any way, which I initially thought when I first sent this bug report. It still dies on the same queries as before, in the middle of iterating through ou=users,.. or ou=groups,.., which both have ~1.8k entries. These queries comes from proftpd, which does a "getent passwd" and "getent group" every time a customer logs in. I tried to reproduce this manually again, launching 8 processes, constantly querying ou=users and ou=groups, 2 using a unix socket locally and 6 using ldaps://hostname/ remotely, but it still won't break down when I do that. This causes *alot* more load than proftpd does, but the crashes seem to only happen "randomly". Any suggestions on what I can do to figure out this problem? The LDAP server is live and in use in two servers with 2-3k users, so I can't mess with it *too* much. On Fri, Oct 02, 2009 at 09:28:25PM +0000, quanah(a)zimbra.com wrote: >--On Friday, October 02, 2009 8:54 PM +0000 hyc(a)symas.com wrote: > > >> strace is useless. Use gdb and get a trace of all running threads when >> this occurs. >> >> http://www.openldap.org/faq/data/cache/59.html > > >You also need to test against a current release of OpenLDAP, like OpenLDAP >2.4.18. > >--Quanah > > >-- > >Quanah Gibson-Mount >Principal Software Engineer >Zimbra, Inc >-------------------- >Zimbra :: the leader in open source messaging and collaboration > > -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 10 Dec '09

10 Dec '09

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> The problem is that back-relay presents slapo-rwm(3) an entry with both >> REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a >> consequence, the entry is released (namely, freed) before it is returned >> by the frontend. As far as I understand, the two flags should be mutually >> exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is >> supposed to be a copy of an entry that may need to be released, or an >> entry created from scratch and thus not stored anywhere. I have a quick >> fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when >> REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in >> tracking where the issue occurs. Unless I track it, I'll commit the quick >> fix. > > We already have ITS#5340 for issues with these flags... Right. I asked him to open an ITS because I though the error was in slapo-rwm; my first fix was in that area. Soon after, I realized the error was in slapo-dynlist, related to ITS#5340. p.

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

I wrote: > Otherwise it should use rs_ensure_entry_modifiable(). Currently > it's still wrong: Discards the old entry without obeying sr_flags. Unless dynlist_sc_save_entry() handles it, I haven't yet tried to figure out the state when it is called. But it looks wrong: it saves and clears rs->sr_entry without saving/clearing (rs->sr_flags & REP_ENTRY_MASK). Here is a draft for what rs_ensure_entry_modifiable() usage is supposed to look like, though I haven't tested it well and I'm going home now. I'm unsure of the translucent code. rwm looks a bit weird, but that's mostly to assert that some functions that receive rs won't modify it. I haven't touched dynlist, don't know what entry ownership is there. http://folk.uio.no/hbf/OpenLDAP/slapreply-draft.diff -- Hallvard

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 09 Dec '09

09 Dec '09

ldapwhoami has the same behaviour [root@ldap1 ~]# time ldapwhoami -xZZh ldap1.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m4.835s user 0m0.021s sys 0m0.012s [root@ldap1 ~]# time ldapwhoami -xZZh ldap2.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m0.042s user 0m0.023s sys 0m0.013s

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

I've been trying to do too much at once in this ITS. My macros can be simplified to at least use functions for the exposed API. Since we now have commits related to this (ITS#6423), there's no reason not to use a common function for the new commits, instead of trying to get it right each time. I've committed a variant of this, so far unused: slap.h REP_ENTRY_MUSTFLUSH, result.c rs_replace_entry(), rs_ensure_entry_modifiable() When an overlay can wants to update rs->sr_entry it can use these. Exception: Some code may want to temporarily replace the entry and later restore it. That should be by a push/pop of sr_entry and (sr_flags & REP_ENTRY_MASK) together. That is, push: <save rs->sr_entry and rs->rs_flags>; rs->sr_flags &= ~REP_ENTRY_MASK; rs->sr_entry = new entry; rs->sr_flags |= new entryflags, if any; pop: rs_replace_entry(op, rs, on, <old entry>); rs->sr_flags |= (<saved flags> & REP_ENTRY_MASK); Maybe this is what dynlist.c:dynlist_prepare_entry() wants to do? I don't see why else it waits to the end of the function to set rs->sr_flags/sr_entry to the _new_ flags and entry. Otherwise it should use rs_ensure_entry_modifiable(). Currently it's still wrong: Discards the old entry without obeying sr_flags. I don't know what overlay to pass to entry_modifiable though. -- Hallvard

1 0

(ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 09 Dec '09

09 Dec '09

Full_Name: Pavel Lisy Version: 2.4.19 or 2.4.20 OS: linux - CentOS4/5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.132.159.239) I have my rpm built on source from Fedora 12. ldapsearch have delay on start, slapd is heavy loaded (up to 90% proc) on the same machine over TLS/SSL only (numbers below) [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m2.610s user 0m0.029s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-z.log 2>&1 real 0m2.700s user 0m0.026s sys 0m0.013s [root@ldap1 ~]# time ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search.log 2>&1 real 0m0.021s user 0m0.010s sys 0m0.008s [root@ldap1 ~]# time ldapsearch24 -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2.log 2>&1 real 0m0.027s user 0m0.009s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-z.log 2>&1 real 0m0.070s user 0m0.028s sys 0m0.020s [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-zz.log 2>&1 real 0m0.048s user 0m0.026s sys 0m0.017s This means: delay is there when I query from the same machine over TLS/SSL, not across machines. I suppose it is bug but I cannot find where it is. When I've changed in slapd.conf "loglevel 0" to "loglevel 1" delay is gone [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m0.315s user 0m0.030s sys 0m0.025s When I start ldapsearch24 through strace delay was in part with stars: ------------ cut --------------- munmap(0x2b2edf8b1000, 4096) = 0 brk(0x15747000) = 0x15747000 write(2, "TLS trace: SSL_connect:before/co"..., 53TLS trace: SSL_connect:before/connect initialization ) = 53 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4 fstat(4, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0 poll([{fd=4, events=POLLIN}], 1, 10) = 1 ([{fd=4, revents=POLLIN}]) read(4, "D~j?,\274k\310mx\336\t\17k\207Q\322\0369SDB\260\241bd6[R}6\201"..., 48) = 48 close(4) = 0 getuid() = 0 write(3, "\200t\1\3\1\0K\0\0\0 \0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"..., 118 *********************************************** DELAY 2s HERE *********************************************** ) = 118 write(2, "TLS trace: SSL_connect:SSLv2/v3 "..., 53TLS trace: SSL_connect:SSLv2/v3 write client hello A ) = 53 read(3, "\26\3\1\0J\2\0", 7) = 7 read(3, "\0F\3\1K \10\5\232\0\3\2\354\235\351\233\276\31\242\302\217\214\35\32\370cGH\342\277\7;"..., 72) = 7 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 49TLS trace: SSL_connect:SSLv3 read server hello A ) = 49 read(3, "\26\3\1\6\303", 5) = 5 read(3, "\v\0\6\277\0\6\274\0\2\2500\202\2\2440\202\2\r\2\3\20\0\0010\r\6\t*\206H\206\367"..., 1731) = 1731 write(2, "TLS certificate verification: de"..., 191TLS certificate verification: depth: 1, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS certificate verification: de"..., 146TLS certificate verification: depth: 0, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 55TLS trace: SSL_connect:SSLv3 read server certificate A ) = 55 read(3, "\26\3\1\0\4", 5) = 5 read(3, "\16\0\0\0", 4) = 4 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 48TLS trace: SSL_connect:SSLv3 read server done A ) = 48 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 57TLS trace: SSL_connect:SSLv3 write client key exchange A ) = 57 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 56TLS trace: SSL_connect:SSLv3 write change cipher spec A ) = 56 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 46TLS trace: SSL_connect:SSLv3 write finished A ) = 46 write(3, "\26\3\1\0\206\20\0\0\202\0\200\202\365\233\356\r\26\27\330\251\17\330\331\3362\23\231\211`\\\262\32 write(2, "TLS trace: SSL_connect:SSLv3 flu"..., 40TLS trace: SSL_connect:SSLv3 flush data ) = 40 read(3, "\24\3\1\0\1", 5) = 5 read(3, "\1", 1) = 1 read(3, "\26\3\1\0000", 5) = 5 read(3, "\353;\20\337y\307&\331\207@#\265\314\267\240\244\177P\223\216\221\216!\"G \27\265R\3078l"..., 48) = write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 45TLS trace: SSL_connect:SSLv3 read finished A ) = 45 write(2, "ldap_sasl_bind\n", 15ldap_sasl_bind ) = 15 write(2, "ldap_send_initial_request\n", 26ldap_send_initial_request ) = 26 write(2, "ldap_send_server_request\n", 25ldap_send_server_request ) = 25 write(2, "ber_scanf fmt ({it) ber:\n", 25ber_scanf fmt ({it) ber: ) = 25 write(2, "ber_scanf fmt ({i) ber:\n", 24ber_scanf fmt ({i) ber: ) = 24 write(2, "ber_flush2: 44 bytes to sd 3\n", 29ber_flush2: 44 bytes to sd 3 ) = 29 write(3, "\27\3\1\0 \217\244v\31\275A\232=\300\357\330\312*\316)\311\23\242\260\350n\353\373\221\204B\v"..., write(2, "ldap_result ld 0x156816c0 msgid "..., 34ldap_result ld 0x156816c0 msgid 2 ) = 34 write(2, "wait4msg ld 0x156816c0 msgid 2 ("..., 50wait4msg ld 0x156816c0 msgid 2 (infinite timeout) ) = 50 write(2, "wait4msg continue ld 0x156816c0 "..., 46wait4msg continue ld 0x156816c0 msgid 2 all 1 ) = 46 write(2, "** ld 0x156816c0 Connections:\n", 30** ld 0x156816c0 Connections: ) = 30 write(2, "* host: ldap1.ldapnet.tmapy.cz "..., 53* host: ldap1.ldapnet.tmapy.cz port: 389 (default) ) = 53 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected ) = 31 write(2, " last used: Wed Dec 9 21:26:51"..., 39 last used: Wed Dec 9 21:26:51 2009 ------------ cut --------------- How can I debug it more? I will send more details if you want.

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 09 Dec '09

09 Dec '09

--On Wednesday, December 09, 2009 12:56 PM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: 2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > Bus error > [root@dc1 openldap]# Please provide a GDB backtrace of the crash with full debugging symbols. Thanks --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs