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.
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1806
I have a system with a reproducible problem with sssd when under load.
The sssd.log shows a reoccurring number of messages stating: A service PING timed out on [domain.com]. Attempt [0]
Followed by: Killing service [expertcity.com], not responding to pings!
Following a restart of sssd, the sssd_be process spikes at 99% cpu, and a delay of 30-60secs can be experienced sshing to the device. Subsequent logins seem fine until whichever cache is effected needs to be renewed again, which in turn reproduces the long delay.
The system is a VM with 2 cores assigned. Load can be anywhere from 4-12 to reproduce the issue.
(In reply to Namita Soman from comment #1)
> Please add steps to verify this
To reproduce, create a very large hostgroup. I used 2000 hosts for my testing, then the bug was visible. Then create an HBAC rule that references this hostgroup. Make sure to disable the allow_all rule for the test. Then log in to the client.
With the unpatched SSSD, the CPU will spike for a couple of seconds. With the patch, the login should be quite faster and there should be no CPU spike.
I would also advise to make sure the user is not a member of large groups to avoid the memberof plugin doing much work during login. That way the only CPU-intensive task is saving the large hostgroup.
Alternatively (or in addition) you could check that the "member" attribute is not downloaded from the server at all.
Tested using ipa-server-3.3.3-18.el7.x86_64, sssd-1.11.2-40.el7.x86_64, ipa-client-3.3.3-18.el7.x86_64
Added a host group - hostgroup1
Added 2000 hosts
Added these hosts to the hostgroup
Installed ipaclient, and added that host to same hostgroup
Added hbac rule, allowing user (user one) to access hosts in the hostgroup (hostgroup1), and allowing access to a service (sshd).
Disabled hbac rule allow_all
Ran kdestroy
ssh'd as user (one) from master server to the host where the rhel 7 client is installed.
Was able to login fast.
There was no cpu spikes or messages in sssd_testrelm.test.log
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.