Bug 885078
| Summary: | sssd_nss crashes during enumeration if the enumeration is taking too long | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kaushik Banerjee <kbanerje> | ||||
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Kaushik Banerjee <kbanerje> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 6.4 | CC: | dpal, grajaiya, jgalipea, mniranja, okos, pbrezina | ||||
| Target Milestone: | rc | Keywords: | Regression | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | sssd-1.9.2-55.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: |
No documentation needed.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-02-21 09:42:24 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 895654 | ||||||
| Attachments: |
|
||||||
Upstream ticket: https://fedorahosted.org/sssd/ticket/1702 Kaushik can you try and reproduce the issue again? I can't see the crash with git head. Using the builds from the previous comment, I haven't seen nss crash. However I still do see the following issues: 1. Enumeration go on forever using bind-credentials. Whereas with anonymous bind(without ldap_default_bind_dn), enumeration of 30k users got over in less than 2mins. 2. Enumerating 30k users using non-anonymous bind makes sssd_be hog the cpu(98%) forever. (In reply to comment #6) > Using the builds from the previous comment, I haven't seen nss crash. > > However I still do see the following issues: > 1. Enumeration go on forever using bind-credentials. Whereas with anonymous > bind(without ldap_default_bind_dn), enumeration of 30k users got over in > less than 2mins. > > 2. Enumerating 30k users using non-anonymous bind makes sssd_be hog the > cpu(98%) forever. OK, these two are bad as well. Can you please file a separate bug and also check out if the same happened with 6.3 packages? To check out whether it is a regression or not, which would help us evaluate the priority. Upstream ticket: https://fedorahosted.org/sssd/ticket/1717 There was a paging configuration issue on my ldap server that made me see different issues for anonymous and non-anonymous binds as discussed in comment 6. I either case, sssd_be hogs the cpu for a very long time. I have opened bug 888739 in that regards. Verified in version sssd-1.9.2-72 Verified manually. Crash is no longer seen. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0508.html |
Created attachment 659350 [details] Backtrace of sssd_nss crash Description of problem: sssd_nss crashes during enumeration and with ldap_default_bind_dn in sssd.conf Version-Release number of selected component (if applicable): 1.9.2-34 How reproducible: Almost always. The crash is in middle of enumerating 30k users on the ldap server. Steps to Reproduce: 1. Setup sssd with the following in domain section: [domain/LDAP] enumerate = True debug_level = 0xFFF0 cache_credentials = True ldap_search_base = dc=example,dc=org id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://ldapserver.example.org ldap_default_bind_dn = cn=Manager,dc=example,dc=org ldap_default_authtok = password 2. Observe the domain log. Wait for enumeration to complete. Actual results: Enumeration goes on forever. And sssd_nss crashes after sometime. See attachment for backtrace. sssd_be cpu usage is about 98% 21727 root 20 0 383m 167m 3572 R 98.1 16.9 1:09.61 sssd_be Expected results: Enumeration should complete and sssd_nss should not crash. Additional info: