Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
kernel: sssd_nss[15721]: segfault at 94 ip 0000003124024fbc sp 00007fff401c4070 error 4 in libdbus-1.so.3.4.0[3124000000+40000]
Version-Release number of selected component (if applicable):
sssd-1.9.2-129.el6_5.4.x86_64
How reproducible:
unknown
Steps to Reproduce:
1.N/A
Actual results:
sssd_nss segfaults
Expected results:
no segfaults
Additional info:
will also provide coredump, bt and sosreport
The customer said this began occurring after the server was patched on the 26th to the latest version of sssd.
Jan 26 09:08:25 Updated: sssd-1.9.2-129.el6_5.4.x86_64
According to log files and coredump, it looks like sssd_nss crashed at the same time when sssd_be was forced to restart because it did not respond to the main sssd process.
I can see that enumeration is enabled and it can be root cause why sssd_be is not responsive. (sssd_be was restarted 50 times per 30 hours and sssd_nss crashed 8 times). Even if we solve crash in sss_nss sssd will not return correct response. I would suggest either to turn off enumeration or increase default value of option "timeout" from 10 seconds to 20 seconds
(In reply to hgraham from comment #5)
> Lukas, would that be the "timeout" option under the [domain/default] section
> of the configuration or under the [nss] ?
Under [domain]
(In reply to hgraham from comment #5)
> Lukas, would that be the "timeout" option under the [domain/default] section
> of the configuration or under the [nss] ?
I should have been more concrete in the previous comment
They should put "timeout = 20" into [domain/default] section.
I think 15 seconds can be also sufficient and I would not recommend to use higher value then 20 seconds.
The customer case is closed. Since the problem was caused by enumeration taking too long which we track already in several other bugzillas, I'm going to close this BZ as UPSTREAM. We need to solve the enumeration performance rather than put band-aids all around.