SSSD / sssd

#3369 ldap_purge_cache_timeout in RHEL7.3 invalidate most of the entries once the cleanup task kicks in
Closed: Fixed Opened by pbrezina.

Closed: Fixed
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1430415

Description of problem:
Customer said:"Our intention is to have the entire ldap catalog in the local
cache and for that purpose we have set "enumerate = true" but but every 3 hours
when ldap_purge_cache_timeout is done all accounts, groups and sudo rules is
removed from the local cache. After 3 hours again all entries is back in the
local cache". The customer is fully aware of the performance impact when using
enumerate.
The customer claims that the issue is perceived on servers running 7.3 and sssd
1.14.0 release 43.el7_3.11, but seemed to work fine in rhel 6 and sssd 1.13.3
rel 22.
According to "man sssd-ldap", if enumeration is enabled, the cleanup task, i.e.
ldap_purge_cache_timeout is required in order to detect entries removed from
the server and can't be disabled!
Version-Release number of selected component (if applicable):
sssd 1.14.0 release 43.el7_3.11
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
  1. Full enumeration fills cache with users and groups
    -- for next three hours enumeration will be usen entryUSN to fetch only new entries
  2. Purge cache timeout kicks in
    -- Full enumeration is done, but it only updates timestamp cache
    -- We search users in data cache with expiriration time filter
    -- We end up deleting all users
  3. Again only smart enumeration with entryUSN is used, which won't get any result
  4. Purge cache timeout
    -- Full enumeration will populate the cache
    -- None users and groups are expired

Please, also check that refresh_expired_interval doesn't have the same issue.

Metadata Update from @pbrezina:
- Issue set to the milestone: None

Not sure while the milestone got set to none. I'm setting it to needs triage.

Metadata Update from @pbrezina:
- Issue set to the milestone: NEEDS_TRIAGE

We do not use "needs_triage" anymore. Missing milestone means that it need to be triaged.

Metadata Update from @lslebodn:
- Issue set to the milestone: None (was: NEEDS_TRIAGE)

Metadata Update from @jhrozek:
- Issue priority set to: critical
- Issue set to the milestone: SSSD 1.15.3

Metadata Update from @fidencio:
- Issue assigned to fidencio

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1430415

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1430415

Issue linked to Bugzilla: Bug 1430415
  • master:
  • 05e579691b51ac2f81ab0c828ff6fe57bd86a8b6
  • 41708e1e500e7cada3d3e606aa2b8b9869a5c734
  • a71f1a655dcc2ca6dc16bb8eb1c4c9e24cfe2c3e
  • 9883d1e2913ff0c1db479f1ece8148e03155c7f3
  • 8ad57e17779b3ec60246ac58c1691ee15745084c
  • 347be58e1769ba90b49a7e5ec1678ef66987f6cd
  • 01c6bb9b47401f9f14c4cfe5c5f03fce2e63629b

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

sssd-1-14:

  • 3c7e9fb3129c3b4398f5e407c5bea99e4e693a52
  • 83f0231ce5dcf7bc9c1a43fcc3f79d7af6ab6d1a
  • b783fbf7614afb4d9e882a70ac63f560f28b8a29
  • 17f4825ff0a77f08e7f761686f8d57206ca025ed
  • 7db486af2b45eac0847bcc78c1a23164bacd8d7f
  • 70807879c27b217057b0ff0e0890dd4d9e3113a2
  • 281ec8da6dd9c93f026e617dc35073dbffb6e0e2
  • 8f6b72385150ed2dba3463e13836def7d8a4383b

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/4399

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.
Metadata
None
None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.