Red Hat Bugzilla – Bug 885078
sssd_nss crashes during enumeration if the enumeration is taking too long
Last modified: 2013-02-21 04:42:24 EST
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):
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:
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.
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
Enumeration should complete and sssd_nss should not crash.
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.
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.