Hide Forgot
Description of problem: The sssd process restarted by itself. At this time, sssd process logged in system and sssd logs as below. 1).The sssd process logged sssd_be start up/down in /var/log/messages. [messages] Jan 9 11:35:11 jonah sssd[be[LDAP]]: Starting up Jan 9 11:36:33 jonah sssd[be[LDAP]]: Shutting down 2).The sssd process logged "global_check_handler" in /var/log/sssd/sssd.log. [sssd.log] (Mon Jan 9 11:36:34 2012) [sssd] [global_checks_handler] (0): Unknown child (1976) did exit Version-Release number of selected component (if applicable): kernel-2.6.32-131.0.15.el6 sssd-1.5.1-66.el6_2.1 sssd-client-1.5.1-66.el6_2.1 How reproducible: Unknown Steps to Reproduce: Unknown Actual results: The sssd_be restarted by sssd. Expected results: The sssd_be doesn't restart by sssd. Additional info: We found a similar bz(BZ#748818) on Bugzilla. In this bz, we know that this bug fixed for sssd of RHEL5. And so compared it and sssd of RHEL6, but this patch already applied to sssd of RHEL6. So, we think that theses are not same bug. If you need more information to investigate this problem, could you please ask us. And this customer ask us a few questions as blow: 1).Set "ldap_purge_cache_timeout" option. -Is there any bad influence with "ldap_purge_cache_timeout=0" in sssd.conf? -If set "ldap_purge_cache_timeout=0", ldap cache(database) keep increase? 2).User authentication response delayed. -This customer use LDAP to authenticate mail user. But LDAP authentication response delayed every several weeks. If you know that fix to delay response to ldap server and from client, could you provide information? And now this customer has been trying to "ldap_purge_cache_timeout=0" option.
What happened here is that the monitor process terminated and restarted an unresponsive sssd_be process. There was a bug (fixed somewhere in the 1.6.x line) where under certain circumstances, the monitor would stop being able to communicate with the sssd_be process. It would interpret this as the process being hung and would send it a SIGTERM and start up a new provider. The reason for that error message was a related bug. The service would start up the new process before the previous one finished exiting, so the monitor lost track of which child it was. It was a harmless error, but also fixed in 1.6.x. For the record, RHEL 6.3 will be rebasing to the forthcoming SSSD 1.8.0 release, so this issue should be resolved then.