openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6071) LDAP server becomes unresponsive
by rs1542＠gmx.com 22 Apr '09

22 Apr '09

Full_Name: Carsten T. Rieck Version: 2.4.11 OS: RedHat 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.194.157.126) Hello, my company runs an anonymously accessible LDAP server on openLDAP 2.4.11 with Berkeley database 4.6.21 (all recent patches applied) and RedHat 5.1 as operating system. We encounter the problem that occasionally the LDAP server becomes unresponsive. Investigating the network in such a situation shows a large number of connections in the state CLOSE-WAIT. These connections remain persistent until the LDAP server is restarted. I am able to reproduce the issue in our test environment using a client which accesses the LDAP using libldap. In an infinite loop, the client binds to the LDAP and performs a search, but it does do a proper unbinding. After about thirty loops (depending on the number of threads configured), the LDAP server becomes unresponsive. With netstat, I see the connection still as ESTABLISHED. After killing the client, the connection is marked as CLOSE-WAIT and remains in that state until the server is restarted. Any additional attempts to bind to the server leads to a connections in state CLOSE-WAIT. I do not have a Firewall in my test environment. When the server becomes unresponsive, the log displays the message "Resource temporarily unavailable" as in the following extract: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: => acl_mask: access to entry "cn=ACME Class 2 CA,o=ACME AG,ou=rootcerts,dc=acme,dc=de", attr "certificateRevocationList;binary" requested Apr 21 18:31:43 test2 slapd[644]: => acl_mask: to value by "", (=0) Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-admin,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-audit,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: anonymous Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] applying =rscx (stop) Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] mask: =rscx Apr 21 18:31:43 test2 slapd[644]: => slap_access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: => access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: activity on 2 descriptors Apr 21 18:31:43 test2 slapd[644]: daemon: activity on: Apr 21 18:31:43 test2 slapd[644]: 12w Apr 21 18:31:43 test2 slapd[644]: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero In the openLDAP mailing lists I have seen other users having similar although not identical problems. The common advice of reducing the parameter idletimout did not change the behavior. I am most pleased to provide any further information. I appreciate your help. Best regards, Carsten slpad.conf ##================================= ## include /usr/machine/local/admin/openldap/config/ldapdsa/schema/core.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/cosine.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/inetorgperson.schema password-hash {SSHA} ###################### # generic parameters # ###################### idletimeout 2 sizelimit 1000 timelimit 2 sockbuf_max_incoming 300000 sockbuf_max_incoming_auth 5000000 threads 4 gentlehup on #################### # pid & args files # #################### pidfile /usr/machine/local/work/openldap/slapd.pid argsfile /usr/machine/local/work/openldap/slapd.args ############################################################################### ################## # ssl parameters # ################## ###################### # used cipher suites # ###################### TLSCipherSuite HIGH:MEDIUM:+SSLv3 ################### # key, certs etc. # ################### TLSVerifyClient never ############################################################################### ################################## # macro bdb database definitions # ################################## ########################################## # suffix dc=acme,dc=de # ########################################## database bdb suffix "dc=acme,dc=de" cachesize 8000 checkpoint 5 30 mode 0600 directory /usr/machine/local/persistent/openldap/acme lastmod on rootdn "cn=admin,dc=acme,dc=de" rootpw <Passphrase removed> limits anonymous size.soft=10 ########################################## # ACLs # ########################################## include /usr/machine/local/admin/openldap/config/ldapdsa/acl.conf ############# # set index # ############# index default pres,eq index objectclass index cn,sn pres,eq,sub index mail #eof ##=================================

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 21 Apr '09

21 Apr '09

bryan.mesich(a)ndsu.edu wrote: > I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 > and recompiled. Slapd answers one request and then dies with > a segmentation fault: > > connection_get(14): got connid=3D1 > connection_read(14): checking for input on id=3D1 > ber_get_next > Segmentation fault > > I can send you the full debug output if it would be helpful. I'll ask you to send it unless I can easily reproduce the issue myself. Thanks for your time. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by bryan.mesich＠ndsu.edu 20 Apr '09

20 Apr '09

--17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2009 at 12:12:48PM +0200, Pierangelo Masarati wrote: >> Full_Name: Bryan Mesich >> Version: 2.4.13 >> OS: RHEL 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) >> >> >> When a rwm overlay is used in conjunction with the translucent overlay, = slapd >> dies with the following error and backtrace: > > I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could = =20 > also address yours. Can you check? You need to either build HEAD code, = =20 > or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> =20 > 1.119 to 2.4.16. I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 and recompiled. Slapd answers one request and then dies with a segmentation fault: connection_get(14): got connid=3D1 connection_read(14): checking for input on id=3D1 ber_get_next Segmentation fault I can send you the full debug output if it would be helpful. Thanks, Bryan --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJ7N6JlSl3SAlkhEcRAuOwAJ42EyL1dRJAFlZVz7zo5LMTCbgEeACePomd GlMyb+gwM6ZgvTkYl60S7h4= =t8Kh -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--

1 0

Re: (ITS#6058) slapcat aborts on a double free
by lscamoni＠alice.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed

1 0

Re: (ITS#6058) slapcat aborts on a double free
by luca.scamoni＠sys-net.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6058) slapcat aborts on a double free
by ando＠sys-net.it 20 Apr '09

20 Apr '09

The problem is that slapcat uses be_entry_release_r() as the complement of be->be_entry_get(), namely a run-time function as the complement of a tool function. rwm_entry_release_rw(), on the contrary, assumes that the entry it is passed was dup'ed by rwm_entry_get_rw(). I've applied a fix which **should** always work, based on the assumption that if the entry was retrieved using rwm_entry_get_rw(), and duplicated, both e->e_private and e->e_bv are NULL. p. luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** > > To simulate it's enough a slapd.conf containing something like > > # Load dynamic backend modules: > modulepath /usr/local/openldap/sbin > moduleload back_hdb.la > moduleload rwm.la > > database hdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory /usr/local/openldap/var/data > index objectClass eq > index entryCSN,entryUUID eq > > overlay rwm > > Simple database: > > dn: dc=example,dc=com > objectClass: dcObject > objectClass: organization > dc: example > o: example.com > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6034) Assert failure - connection_state_closing
by David Angerer 20 Apr '09

20 Apr '09

Hi there, We upgraded to openldap 2.4.16 about 10 days ago. Since then we are experiencing relatively frequent core dumps (average uptime is around 2-3 days). Investigating the root cause we came across ITS#6034 which reminded us much of problem we are facing, but should be fixed in 2.4.16. Setup: Solaris 10 Openldap 2.4.16 (64bit) Berkeley DB 4.7 1 Master 5 Replicas with deltasyncrepl Cores only happened to the master so far, replicas are running stable so far. I couldn't find a reference to this ITS in the 2.4.16 changelog (probably listed as other ITS or fixed earlier). Also if the fix made it's way into 2.4.16, I am wondering why we still observe this cores. If you need further information or have any suggestions please let me know. Please find some debugging information below. Kind regards, David (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x1004dd428 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x1004dd670 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in __lwp_kill() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() > t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in slap_access_allowed() t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x1004dd1e0 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in __lock_getlocker_int() (dbx) lwp l@10 Current function is connection_state_closing 686 assert( c->c_struct_state == SLAP_C_USED ); t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7decea10 (dbx) where [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), line 148 in "result.c" [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = 0xffffffff733ff2d0), line 1247 in "result.c" [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = 3), line 848 in "syncprov.c" [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line 913 in "syncprov.c" [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), line 971 in "syncprov.c" [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in "tpool.c" (dbx) list 680,690 680 int connection_state_closing( Connection *c ) 681 { 682 /* c_mutex must be locked by caller */ 683 684 int state; 685 assert( c != NULL ); 686 assert( c->c_struct_state == SLAP_C_USED ); 687 688 state = c->c_conn_state; 689 690 assert( state != SLAP_C_INVALID ); (dbx) print c c = 0x1004dce30 (dbx) print *c *c = { c_struct_state = 1 c_conn_state = 0 c_conn_idx = 26 c_sd = -1 c_close_reason = 0x100271eb0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x118772d90 c_starttime = 0 c_activitytime = 0 c_connid = 18446744073709551615U c_peer_domain = { bv_len = 0 bv_val = (nil) } c_peer_name = { bv_len = 0 bv_val = (nil) } c_listener = (nil) c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x1004dcf38 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x1004dcf48 } c_write1_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190080U } __pthread_mutex_owner64 = 4278190080U } __pthread_mutex_data = 18446744071451976704U } c_write1_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_write2_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write2_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_writers = 0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = (nil) c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 3 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 3 c_n_get = 4 c_n_read = 3 c_n_write = 1 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x10006b900 = &slap_send_ldap_result(Operation *op, SlapReply *rs) c_send_search_entry = 0x10006cda0 = &slap_send_search_entry(Operation *op, SlapReply *rs) c_send_search_reference = 0x10006fa80 = &slap_send_search_reference(Operation *op, SlapReply *rs) c_send_ldap_extended = 0x10006c5f8 = &slap_send_ldap_extended(Operation *op, SlapReply *rs) c_send_ldap_intermediate = 0x10006ca28 = &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) }

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 20 Apr '09

20 Apr '09

bryan.mesich(a)ndsu.edu wrote: > Full_Name: Bryan Mesich > Version: 2.4.13 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) > > > When a rwm overlay is used in conjunction with the translucent overlay, slapd > dies with the following error and backtrace: I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could also address yours. Can you check? You need to either build HEAD code, or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> 1.119 to 2.4.16. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6070) slapo-rwm(5) be_entry_get() incorrect behavior when no DN rewriting occurs
by ando＠sys-net.it 20 Apr '09

20 Apr '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando To reproduce, stack a slapo-rwm with no specific instructions on top of a provider right before the syncprov overlay. A fix is coming.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: >> (I've stumbled across ITS#5704. Isn't that already something like this?) > > not exactly, as sets do not allow a placeholder for the naming > attribute; maybe something like "this/entryRDN.ava{0}.value" if it > existed... But given that slapd already enforces the characteristic attribute (e.g. 'cn' for 'user' on Samba4) to be part of the entry IMHO this is not needed. Provided the order of the checks are right. So this would be: constraint_attribute name set "this/cn" restrict="ldap:///dc=example,dc=com??sub?(objectClass=user)" constraint_attribute name set "this/ou" restrict="ldap:///dc=example,dc=com??sub?(objectClass=organizationalUnit)" Since uniqueness of 'cn' or 'ou' for one-level search for the above cases is already enforced wouldn't this be sufficient? Maybe I miss something though. Ciao, Michael.

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