On Thu, Apr 16, 2015 at 11:37:53AM +0200, Jean-Baptiste Denis wrote:
I was suspecting a race condition, because as well as the rest of SSSD, the cleanup task is asynchronous. I was suspecting the following might have happened: - initgroups starts: - users are written to the cache - groups are written to the cache but not linked yet to the user objects - cleanup tasks starts - cleanup task removes the group objects because they are "empty". It shouldn't happen because the cleanup task should only remove expired entries, but IIRC Lukas saw a similar race-condition elsewhere.
"groups are written to the cache but not linked yet to the user objects"
Is it possible for the responder to answer a client about groups information before the groups are written to the cache AND linked to it ? That's what the getgroups syscall (from the client) returning the wrong number of group would suggest when the problem occurs. Could that be related to ghost or fake entries ?
No, it shouldn't be. The whole backend request should run and only then the backend should signal to frontend to re-check the cache. That's why I was suspecting the cleanup task, it's asynchronous.