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