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().