URL: https://github.com/SSSD/sssd/pull/947
Title: #947: tests: fix race conditions in integration tests
alexey-tikhonov commented:
"""
> > > `poll_canary` has no meaning as we currently block when refreshing the
> > > cache. We can either remove it or report a bug against sssd that it
> > > behaves incorrectly. @jhrozek When files provider is updating cache in
> > > inotify callback (i.e. domain is inconsistent) should nss responder A)
> > > return not found and let client look in files database, or B) block until
> > > the cache is updated? Currently B is true but tests says A should be done.
> >
> > Actually... Are you sure "B is true"?
> > I just tested with a patch of `providers/files/files_ops.c:sf_passwd_cb()`:
> > `+ while (1) { usleep(100000); }`
> > right before `sf_enum_files()` and `id` works fine (according to your
> > statement this should block).
>
> Because you used `usleep` at wrong place.
I see your point but still I think I used `usleep()` at *right* place. I wished
to simulate a case when `sf_enum_files()` blocks (takes very long time) and
from my point of view `usleep()` right before `sf_enum_files` simulates this
well.
And thanks to your hint this experiment actually exposed [a
bug](https://github.com/SSSD/sssd/pull/955#issuecomment-562114520)
> See, D-Bus communication is asynchronous so once you put a sleep somewhere,
> the process can not receive nor send any message. In this case, even though
> `dp_sbus_domain_inconsistent` was called, the message was not send because
> you immediately go to sleep.
> Therefore, the nss responder will answer with what it has in cache. You will
> see this in logs.
Indeed. Thanks for pointing this out.
> I'm not sure why it continues with nss_files, I am not this much familiar
> with nss internals.
If I use `getent passwd` it stops after reading (stale) data from nss_responder.
In case of `id` it continues with `libnss_files`. Strange.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/947#issuecomment-562244853
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
