[SSSD-users] sssd-ldap caching issue ?

Jean-Baptiste Denis jbdenis at pasteur.fr
Wed Apr 15 10:05:03 UTC 2015


> I think this means the frontend (responder) either checks too soon or
> the back end wrote incomplete data.

OK.

> The responder is the sssd_nss process. When the getgrouplist() request
> arrives, the cache validity is checked. If the cache is empty or too
> old, the sssd_nss process queries the sssd_be process to update the
> cache. When the sssd_be process is done, it sends a dbus signal (over a
> private unix socket, not the system bus) that the cache is up-to-date
> and the 

Thank you for clarifying that up. It corresponds quite well the model we already
build ourself reading the different design documents on the wiki and your blog
post "Anatomy of SSSD user lookup".
(https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/)

We are not developer per see (and certainly not in C), but we've got a hard time
matching this model to the asynchronous nature of the code using tevent, SBus
and ldb. Try and miss is our best tool at the moment =)

> I wonder if adding another sysdb_initgroups call into
> sdap_get_initgr_recv() would verify when/if the groups were written?

Do you mean litteraly add a call to sysdb_initgroups within this function ?
Is that possible with the res parameter of the sdap_get_initgr_recv function ?

int sdap_get_initgr_recv(struct tevent_req *req)
{
    TEVENT_REQ_RETURN_ON_ERROR(req);

    return EOK;
}

> I tried to write a simple program that just calls getgrouplist() in many
> concurrent threads to simulate your behaviour, but couldn't reproduce
> the problem...

We tried that with processes too, but without able to reproduce the problem either.

Our next step will be to mimic the flow of slurmd on job execution to build a
test case : the slurmd process (double- ?) forks a slurmstepd process that will
call the _initgroups slurm function within the _drop_privileges function :

https://github.com/SchedMD/slurm/blob/master/src/slurmd/slurmstepd/mgr.c

That's our best call at the moment

Jean-Baptiste




More information about the sssd-users mailing list