On Fri, Apr 10, 2015 at 06:08:03PM +0200, Thomas HUMMEL wrote:
Conclusion : it seems to us that it really is an sssd problem. Can
you hint us
somewhere in the sssd source code we can start to further investigate because
we are unable to build a test case without slurm.
Thank you for the logs. Can you tell which was the first failing
request? The very first request in the nss log is received at
16:06:15:464051:
(Thu Apr 9 16:06:15:464051 2015) [sssd[nss]]
[nss_cmd_initgroups_search] (0x0100): Requesting info for
[njoly@pasteur_ldap_home]
There is no cached info, so the request goes to the back end:
(Thu Apr 9 16:06:15:464290 2015) [sssd[nss]] [sss_dp_issue_request]
(0x0400): Issuing request for [0x418850:3:njoly@pasteur_ldap_home]
And completes:
(Thu Apr 9 16:06:15:481246 2015) [sssd[nss]]
[nss_cmd_initgroups_search] (0x0400): Initgroups for
[njoly@pasteur_ldap_home] completed
The another initgroups is received:
(Thu Apr 9 16:06:15:481526 2015) [sssd[nss]]
[nss_cmd_initgroups_search] (0x0100): Requesting info for
[njoly@pasteur_ldap_home]
Which is returned from the cache. So I currently don't see a problem in
the logs, but apparently there is some.
If you want to add more debugging to SSSD, the function to start at is
check_cache(). In particular, the part that decides whether the info is
valid is on line 632 in git master. Also, the part that actually sends
the GIDs back to the client is fill_initgr().