#47559 hung server - related to sasl and initialize
Closed: Invalid None Opened 6 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.

0001-Ticket-47559-hung-server-related-to-sasl-and-initial.patch
0001-Ticket-47559-hung-server-related-to-sasl-and-initial.patch

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

3 years ago

Login to comment on this ticket.

Metadata