#47559 hung server - related to sasl and initialize
Closed: wontfix None Opened 10 years ago by gettes.

389-Directory/1.2.11.15 B2013.238.2155 Nothing in errors, nothing in access log files uname -a Linux XXXX 2.6.32-358.18.1.el6.x86_64 #1 SMP Fri Aug 2 17:04:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux yum list | grep 389 389-admin.x86_64 1.1.29-1.el6 @epel-x86_64-server-6 389-admin-console.noarch 1.1.8-1.el6 @epel-x86_64-server-6 389-admin-console-doc.noarch 1.1.8-1.el6 @epel-x86_64-server-6 389-adminutil.x86_64 1.1.15-1.el6 installed 389-console.noarch 1.1.7-3.el5 installed 389-ds.noarch 1.2.2-1.el6 @epel-x86_64-server-6 389-ds-base.x86_64 1.2.11.15-22.el6_4 @rhel-x86_64-server-6 389-ds-base-debuginfo.x86_64 1.2.11.15-22.el6_4 @rhel-x86_64-server-6-debuginfo 389-ds-base-libs.x86_64 1.2.11.15-22.el6_4 @rhel-x86_64-server-6 389-ds-console.noarch 1.2.6-1.el6 @epel-x86_64-server-6 389-ds-console-doc.noarch 1.2.6-1.el6 @epel-x86_64-server-6 389-dsgw.x86_64 1.1.10-1.el6 @epel-x86_64-server-6 389-admin.i686 1.1.29-1.el6 epel-x86_64-server-6 389-adminutil.i686 1.1.15-1.el6 epel-x86_64-server-6 389-adminutil-devel.i686 1.1.15-1.el6 epel-x86_64-server-6 389-adminutil-devel.x86_64 1.1.15-1.el6 epel-x86_64-server-6 389-ds-base-debuginfo.i686 1.2.11.15-22.el6_4 rhel-x86_64-server-6-debuginfo 389-ds-base-devel.i686 1.2.11.15-22.el6_4 rhel-x86_64-server-optional-6 389-ds-base-devel.x86_64 1.2.11.15-22.el6_4 rhel-x86_64-server-optional-6 389-ds-base-libs.i686 1.2.11.15-22.el6_4 rhel-x86_64-server-6 I have a gcore of ns-slapd #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x00007f6f9c6af3be in _L_lock_995 () from /lib64/libpthread.so.0 #2 0x00007f6f9c6af326 in __pthread_mutex_lock (mutex=0x18c8850) at pthread_mutex_lock.c:101 #3 0x00007f6f9cd050b9 in PR_Lock (lock=0x18c8850) at ../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:174 #4 0x00007f6f9d390bf0 in nssCertificate_Destroy (c=0x1a0f3f0) at certificate.c:112 #5 0x00007f6f9d684e97 in ssl_ResetSecurityInfo (sec=0x2774888, doMemset=0) at sslsecur.c:947 #6 0x00007f6f9d684f1b in ssl_DestroySecurityInfo (sec=0x2774888) at sslsecur.c:978 #7 0x00007f6f9d6891e5 in ssl_DestroySocketContents (ss=0x2774800) at sslsock.c:404 #8 0x00007f6f9d68a752 in ssl_FreeSocket (ss=0x2774800) at sslsock.c:465 #9 0x00007f6f9d6808b8 in ssl_DefClose (ss=0x2774800) at ssldef.c:206 #10 0x0000000000414301 in connection_cleanup (conn=0x7f6f80753670) at ldap/servers/slapd/connection.c:167 #11 0x0000000000415371 in connection_table_move_connection_out_of_active_list (ct=0x1ca7bc0, c=0x7f6f80753670) at ldap/servers/slapd/conntable.c:322 #12 0x0000000000417d66 in setup_pr_read_pds (ports=0x7fff04c632e0) at ldap/servers/slapd/daemon.c:1702 #13 slapd_daemon (ports=0x7fff04c632e0) at ldap/servers/slapd/daemon.c:1137 #14 0x000000000041f0df in main (argc=7, argv=0x7fff04c63678) at ldap/servers/slapd/main.c: did a kill -9 of the server (normal kill had no effect). Server is now back up and running. ============== Rich Megginson replied on the 389 list (after I supplied a proper stack trace): Thanks. Please open a ticket. This looks like https://fedorahosted.org/389/ticket/348 Looks like we need to put a mutex around ldap_sasl_bind in addition to the mutex around ldap_initialize.

what versions of nss and openldap are you using?
rpm -q nss openldap

would you be able to try out a patch? have not been able to reproduce

Please try the following build - http://rmeggins.fedorapeople.org/rpms/

install the 3 -3.1 x86_64 rpms. If you can reproduce the problem, please get a stack trace as before.

To ssh://git.fedorahosted.org/git/389/ds.git
fe52f44..a572cb2 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit a572cb2
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Oct 14 12:43:51 2013 -0600
038b12a..9d7fab3 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit 9d7fab3
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Oct 14 12:43:51 2013 -0600
13dd962..8a7ee90 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 8a7ee90
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Oct 14 12:43:51 2013 -0600
3ceef4b..7b3b2fe 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 7b3b2fe
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Oct 14 12:43:51 2013 -0600
85bc265..da3e4aa master -> master
commit da3e4aa
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Oct 14 12:43:51 2013 -0600

Reverting earlier fix because it breaks ipa
To ssh://git.fedorahosted.org/git/389/ds.git
c783d15..bd0efbd 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit bd0efbd
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Nov 12 12:56:26 2013 -0700
7eefa12..20b8c33 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit 20b8c33
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Nov 12 12:56:02 2013 -0700
fc70e4a..084698e 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 084698e
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Nov 12 12:55:35 2013 -0700
30bb98f..6b16d30 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 6b16d30
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Nov 12 12:54:59 2013 -0700
cb54dfe..941b770 master -> master
commit 941b770
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Nov 11 16:09:37 2013 -0700

This was not a directory server bug, but a bug in nss. This is fixed in NSS in RHEL 6.5 - nss nss-3.15.1-15

Metadata Update from @gettes:
- Issue set to the milestone: N/A

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/896

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

3 years ago

Login to comment on this ticket.

Metadata