I haven't seen this bug in production, but I think it is an issue we should fix.
During the sdap online check, there is a small window where we could have received "Cannot resolve" from fail over, but did not mark the whole "check online" request as done yet. If resolv.conf is updated in that moment, the second online check with updated resolv.conf values wouldn't run because the first online check is still in progress.
Other potential online checks in other providers might suffer from the same issue. I suppose we should fix it in a more generic way on the "online checks" level.
In particular, we should queue a second online check on resolv.conf update and if the first one succeeds (which would be the 90% case, I guess), the second one will be automatically marked as done.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.8.0 owner: somebody => jhrozek
rhbz: => 0
After analysing the issue again we couldn't see a real bug anymore. Closing, we can reopen if the issue hits us again.
blockedby: => blocking: => feature_milestone: => resolution: => worksforme status: new => closed
Metadata Update from @jhrozek: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.8.0 (LTM)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2052
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.