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.
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.
Comment 2Stephen Gallagher
2012-01-30 13:27:20 UTC
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.