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.