#3518 sssd_client: add mutex protected call to the PAC responder
Closed: Fixed 2 years ago Opened 2 years ago by sbose.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1461462

Description of problem:

a customer is hitting the following unresponsiveness:

#0  0x00007f29342dcdfd in poll () from /lib64/libc.so.6
#1  0x00007f2901e722ba in sss_cli_make_request_nochecks () from
/usr/lib64/krb5/plugins/authdata/sssd_pac_plugin.so
#2  0x00007f2901e72a75 in sss_cli_check_socket () from
/usr/lib64/krb5/plugins/authdata/sssd_pac_plugin.so
#3  0x00007f2901e72e07 in sss_pac_make_request () from
/usr/lib64/krb5/plugins/authdata/sssd_pac_plugin.so
#4  0x00007f2901e71feb in sssdpac_verify () from
/usr/lib64/krb5/plugins/authdata/sssd_pac_plugin.so
#5  0x00007f29364ea3d3 in krb5int_authdata_verify () from /lib64/libkrb5.so.3
#6  0x00007f293650b621 in rd_req_decoded_opt () from /lib64/libkrb5.so.3
#7  0x00007f293650c03a in krb5_rd_req_decoded () from /lib64/libkrb5.so.3
#8  0x00007f292d592b3f in kg_accept_krb5 () from /lib64/libgssapi_krb5.so.2
#9  0x00007f292d5941fa in krb5_gss_accept_sec_context_ext () from
/lib64/libgssapi_krb5.so.2
#10 0x00007f292d594359 in krb5_gss_accept_sec_context () from
/lib64/libgssapi_krb5.so.2
#11 0x00007f292d5816d6 in gss_accept_sec_context () from
/lib64/libgssapi_krb5.so.2
#12 0x00007f292d7c3edc in gssapi_server_mech_step () from
/usr/lib64/sasl2/libgssapiv2.so
#13 0x00007f29349e5b9b in sasl_server_step () from /lib64/libsasl2.so.3
#14 0x00007f29349e6109 in sasl_server_start () from /lib64/libsasl2.so.3
#15 0x00007f293719a0a2 in ids_sasl_check_bind ()
#16 0x00007f2937181c2a in do_bind ()
#17 0x00007f2937188aad in connection_threadmain ()
#18 0x00007f2934c1896b in _pt_root () from /lib64/libnspr4.so
#19 0x00007f29345b8dc5 in start_thread () from /lib64/libpthread.so.0
#20 0x00007f29342e773d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f29371218c0 (LWP 17841)):
#0  0x00007f29345bc6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007f2934c13463 in PR_EnterMonitor () from /lib64/libnspr4.so
#2  0x00007f293718dd29 in slapd_daemon ()
#3  0x00007f293717f253 in main ()

A gssapi sasl bind provokes a sssd operation, probably to AD and it's taking
longtime to complete.

During all that time the scheduler cannot assign any new operation to a worker
thread because the connection table is locked by the bind operation.


Version-Release number of selected component (if applicable):
   389-ds-base-1.3.5.10-15.el7_3.x86_64


How reproducible: ipa with AD trust. sssd taking long to discover the server by
dns could be a hint to reproduce this.

Metadata Update from @sbose:
- Custom field patch adjusted to on
- Issue set to the milestone: None

2 years ago

Metadata Update from @sbose:
- Issue assigned to sbose

2 years ago

Metadata Update from @lslebodn:
- Issue close_status updated to: Fixed
- Issue set to the milestone: SSSD 1.15.4
- Issue status updated to: Closed (was: Open)
- Issue tagged with: PR

2 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1461462

2 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

2 years ago

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

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4544

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.

Login to comment on this ticket.

Metadata