It's possible as we've had that happen in the past (and complained loudly to the team that keeps doing it). Is there any way to read those files to see which users/groups are contained in them so we can verify? ldbsearch doesn't seem to read them or I'm giving it the wrong args. If this is already in the troubleshooting/debug docs, I've missed it.
thanks =G= ________________________________________ From: Lukas Slebodnik <[email protected]> Sent: Wednesday, October 4, 2017 8:41 AM To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: sssd email login performance EXTERNAL On (04/10/17 12:18), Galen Johnson wrote: >Thanks, again, Sumit. We recently switched to using tmpfs for the caching >database (per >https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/) > but I don't recall if it was in place when this test was done. Regardless, >we'll try to get another run together and get it back to you. I'll also look >into the cached_auth_timeout option. > >Would there be any benefit in putting /var/lib/sss/mc on tmpfs as well? Also, >what are the *_corrupted files? Is there a way to see the content (like you >can with ldbsearch on the other cached data)? > Did you rename some users/groups in LDAP server? Or do you have colliding UID/GID in LDAP server? Answer to previous question might explain such files. LS _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
