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