#47559 hung server - related to sasl and initialize
Closed: wontfix Opened 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 a572cb299d8b31f270c9d7d53ad799e91c4dc212
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 9d7fab399f334a37e9a27964765a0f9ac4bd14a3
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 8a7ee90d6a770f1732bcd03b20471de3a6162b2b
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 7b3b2fe9d4a7f73a12b4f2d499b2e6a2f80e454b
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Oct 14 12:43:51 2013 -0600
85bc265..da3e4aa master -> master
commit da3e4aa40b04094d0e77052b894b0f0c335ea1ef
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 bd0efbd0dc2e201c9e88e57fe9cce3456e35432c
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 20b8c33a58ed3daa5567d3ba94da4c3eb93ed9ad
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 084698e0af1c7562a4e1d8c787b967ea7fbbcd31
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 6b16d306cf64d66e10d1fa4a33a8997c3ebb5a5e
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Nov 12 12:54:59 2013 -0700
cb54dfe..941b770 master -> master
commit 941b7702bc75cea0b88ce44688d6423478be3a00
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

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)

Metadata