On Thu, Jul 19, 2018 at 2:32 AM Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On 13 Jul 2018, at 00:16, Peter Moody <peter.moody(a)gmail.com> wrote:
> On Wed, Jul 11, 2018 at 12:39 AM Jakub Hrozek <jhrozek(a)redhat.com> wrote:
>> On Tue, Jul 10, 2018 at 08:14:15PM -0700, Peter Moody wrote:
>>> line breaks are in the original logs:
>> Right, I saw this, but can I see more context earlier in the logs? See
> this is everything from sss_cache -E, to after 'id peter' returns info
> for user pmoody
>> Could it be the user itself? I don't know exactly, that's why I asked
>> for more context..
> it could be. I posted the current ldif's for both users in the first
> message. is there something else I should be looking?
Thank you for the logs, they show now clearly where the issue is happening, it looks like
when setting the attributes for the user the user is not cached yet, which sounds bizzare
because the user is looked up in the function before.
But I’m afraid that without stepping through the code with a debugger I won’t be able to
find the reason..I guess I could add a patch with more debug data if you can apply it
yourself (sorry, I have no idea how to patch a debian package) but currently the logs are
not as helpful as I thought.
looping in the debian package maintainers.
thread is here:
the short version is that one user (in three) from my test setup can't
be looked up. I have pmoody, peter, and pjm with consecutive uids
(ldif in the link above). looking up pmoody and pjm works just fine.
looking up peter fails and returns info for pmoody. This is with sssd
1.16.2-1, with user info coming from openldap. Jakub, the redhat
maintainer for sssd has traced the issue down to:
Thank you for the logs, they show now clearly where the issue is
happening, it looks like when setting the attributes for the user the user is not cached
yet, which sounds bizzare because the user is looked up in the function before.