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.
DescriptionNikolai Kondrashov
2013-08-13 14:19:49 UTC
Description of problem:
Sssd initial enumeration sometimes has no effect if an attempt to list groups
is made right after starting sssd.
I.e. "getent group" output doesn't include groups managed by sssd at least up
to 30 seconds after the start, if the first attempt was made within about 0.1s
after the start.
If at least about half a second delay is introduced before first attempt, the
groups appear in "getent group" output.
Version-Release number of selected component (if applicable):
python-sssdconfig-1.11.0-0.1.beta2.el7.noarch
sssd-krb5-common-1.11.0-0.1.beta2.el7.x86_64
sssd-krb5-1.11.0-0.1.beta2.el7.x86_64
libsss_idmap-1.11.0-0.1.beta2.el7.x86_64
libipa_hbac-1.11.0-0.1.beta2.el7.x86_64
sssd-common-1.11.0-0.1.beta2.el7.x86_64
sssd-ldap-1.11.0-0.1.beta2.el7.x86_64
sssd-ad-1.11.0-0.1.beta2.el7.x86_64
sssd-proxy-1.11.0-0.1.beta2.el7.x86_64
sssd-client-1.11.0-0.1.beta2.el7.x86_64
sssd-ipa-1.11.0-0.1.beta2.el7.x86_64
sssd-1.11.0-0.1.beta2.el7.x86_64
How reproducible:
Within 50 attempts
Steps to Reproduce:
Modify the attached "init_enum_failure_test" script to suit local setup and execute it as root.
Actual results:
The script outputs "Group enumeration not retrieved within 5 attempts", exits with status 1.
Expected results:
The script produces no output, exits with status 0.
Comment 1Nikolai Kondrashov
2013-08-13 14:21:09 UTC
Nikolai and I discussed this issue and came to the following conclusion:
1. Enumeration and especially the handling of the initial complete enumeration is far from prefect and should be improved on different levels in the backend but also in the nss responder.
2. The observed behavior is expected and documented in the sssd.conf man page and has not changed since about 2010:
"Note: Enabling enumeration has a moderate performance impact on SSSD while enumeration is running. It may take up to several minutes after SSSD startup to fully complete enumerations. During this time, individual requests for information will go directly to LDAP, though it may be slow, due to the heavy enumeration processing. Saving a large number of entries to cache after the enumeration completes might also be CPU intensive as the memberships have to be recomputed.
While the first enumeration is running, requests for the complete user or group lists may return no results until it completes."
3. The results of an enumeration are cache for a time given by the enum_cache_timeout option (see man sssd.conf as well). As a result by default the initially empty group list is cached for 120s and the client will see an empty group list for this time. This explains the long waiting time when the first 'getent group' request didn't return any groups. Nikolai thinks about changing this option in some tests to make them more reliable.
Jenny, because of 2 I would like to ask you to remove the Regression keyword and the blocker flag. This ticket should be used to track the improvements to enumeration but I think there is no chance to do any substantial improvement in the rhel-7.0 timeframe. Do you agree?
Since this problem is already tracked in an upstream ticket and this bugzilla is not being planned for any immediate release either in RHEL or upstream, I'm closing this bugzilla with the resolution UPSTREAM.
Please reopen this bugzilla report if you disagree.