Learn more about these different git repos.
Other Git URLs
sssd.conf
[sssd] config_file_version = 2 sbus_timeout = 30 services = nss, pam domains = LOCAL [nss] [domain/LOCAL] id_provider = local enumerate = True min_id = 500
and these steps:
service sssd start NAME_PREFIX=`for i in {1..245}; do printf "a"; done` for i in {1..1000000}; do getent passwd -s sss "$NAME_PREFIX$i"; done
Metadata Update from @jhrozek: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1536514
Version of sssd or libtdb is not related because it is reproducible on el6 and also el7 (tested with 7.3 and 7.5) and even on fedora
Metadata Update from @jhrozek: - Issue assigned to mzidek
Metadata Update from @jhrozek: - Issue priority set to: critical
Imo this is not a leak in the typical sense where memory is allocated and later on the reference to the memory got lost and the memory cannot be freed anymore.
The data is allocated for the negative cache and the current logic is that the data will be removed if there is a new request after the negative cache timeout. If there is no such request the data will just stay in the negative cache.
I wonder if an easy solution might be to completely remove the negative cache e.g. during a clearMemcache SBUS request. This would also allow to do a tdb_close()/tdb_open() cycle which hopefully resets the memory consumption of the memory tdb as well.
Since we are near the 1.16.2 release and this ticket has no PR yet, it will slip into 1.16.3.
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 1.16.3 (was: SSSD 1.16.2)
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 1.16.4 (was: SSSD 1.16.3)
I wonder if an easy solution might be to completely remove the negative cache e.g. during a clearMemcache SBUS request.
But if I understand correctly this SBUS request is only triggered by SIGHUP signal sent to Monitor. Do you offer to send this signal periodically and unconditionally?
This would also allow to do a tdb_close()/tdb_open() cycle which hopefully resets the memory consumption of the memory tdb as well.
Does it mean that simple removal of tdb entry doesn't release memory and tdb_close()/tdb_open() cycle is required? If so then from my point of view it sounds like a bug of libtdb...
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 2.2 (was: SSSD 1.16.4)
Metadata Update from @jhrozek: - Custom field blocking adjusted to 4002 - Issue set to the milestone: SSSD 2.3 (was: SSSD 2.2)
Metadata Update from @thalman: - Issue tagged with: bugzilla
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/4658
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.