#3800 ldap_enumeration_refresh_timeout doesn't work
Closed: worksforme 5 years ago Opened 5 years ago by haolee.

Hi,
I encounter a problem when I enable enumeration. I think SSSD will enumerate all entries periodically and the period is controlled by ldap_enumeration_refresh_timeout. However, my SSSD keeps updating the cache all the time and never stops. I have set ldap_enumeration_refresh_timeout and enum_cache_timeout to 3600, but it doesn't work. It's very weird.

My SSSD version is 1.16. I don't know if this is a bug. Could you please help me? Thanks.

The sssd.conf file is as follows:

[domain/default]
enumerate = True
debug_level = 6
autofs_provider = ldap
ldap_schema = rfc2307bis
cache_credentials = True
ldap_search_base = dc=huawei,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://xxx.xxx.xxx.xxx:636
ldap_id_use_start_tls = False
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_enumeration_refresh_timeout = 3600

[sssd]
services = nss, pam, autofs, ssh
domains = default

[nss]
homedir_substring = /home
enum_cache_timeout = 3600

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[secrets]

What does it mean that the enumeration never stops? How large is the directory?

@jhrozek On the client system, the CPU usage of process sssd_be is always 80%~100%. If I change the debug level to 6, the log file sssd_default.log will be updated all the time. In other words, the cache updating will never be finished.

The cache_default.ldb file is approximate 70M and won't grow.
The sssd_default.log will keep growing.

I find that the modified time of cache_default.ldb is not changed but timestamps_default.ldb is updated all the time.

The title of the ticket says that the refresh timeout doesn't work. But are you sure it's not the other way around that the first refresh doesn't even finish until the second one is scheduled?

How large is the domain, how many users or groups are there?

The short answer to enabling enumeration is..don't do it. It means the whole directory is replicated to the sssd cache. If there's more than a couple of hundred entries,it's expected that things will be slow.

Hi, my server has 20,000 users and 20,000 groups.

But are you sure it's not the other way around that the first refresh doesn't even finish until the second one is scheduled?

Thanks for your explanation. Actually, I'm not sure if the second refresh is scheduled before the first round finishing. I will set ldap_enumeration_refresh_timeout to a larger number and test it again. Thanks.

@jhrozek Hi, I have figured out what's wrong with my SSSD client.

When enumerate = True, the CPU usage ofsssd_be is 100% and therefore it can't respond to sssd process promptly. Then sssd considers that sssd_be is unresponsive and restart it. sssd_be will be restarted every one or two minutes because the CPU is exhausted. As a result, the enumeration process becomes extremely slow.

After setting timeout to 300, the enumeration finally complete successfully.

Thanks for your help!

Reference: https://access.redhat.com/solutions/3352181

Metadata Update from @haolee:
- Issue close_status updated to: worksforme
- Issue status updated to: Closed (was: Open)

5 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4795

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata