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 <lslebodn(a)redhat.com>
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-larg...)
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 -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org