Red Hat Bugzilla – Bug 979046
sssd_be goes to 99% CPU and causes significant login delays when client is under load
Last modified: 2013-11-21 17:20:28 EST
+++ This bug was initially created as a clone of Bug #979045 +++ 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.
Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=979045#c2
Fixed upstream.
Tested using ipa-server-3.0.0-36.el6.x86_64, sssd-1.9.2-127.el6.x86_64, ipa-client-3.0.0-36.el6.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 6.5 client is installed. There was no cpu spikes or messages in sssd.log
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/RHBA-2013-1680.html