Learn more about these different git repos.
Other Git URLs
We should handle EPIPE, if sssd_nss crashes and is restarted while a client is trying to send info we'd probably get EPIPE.
While thinking about that I think we should retry also if we get EPIPE on recv(), but in that case we cannot just retry the recv().
In gneral when we get EPIPE we do not know what the server recieved so we should retry the whole operation.
If we add EPIPE handling though the number of retries should be limited though, to avoid infinite loops (both on send() and recv() errors).
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1142351 (Red Hat Enterprise Linux 6)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=1209600 1209600] => [https://bugzilla.redhat.com/show_bug.cgi?id=1209600 1209600], [https://bugzilla.redhat.com/show_bug.cgi?id=1142351 1142351]
design_review: => 0
mark: no => 0
milestone: NEEDS_TRIAGE => SSSD 1.14 beta
review: True => 0
testsupdated: => 0
Moving up to needs_triage, we might need to do this sooner.
milestone: SSSD 1.14 beta => NEEDS_TRIAGE
sensitive: => 0
This ticket was previously in 1.14, but since downstream needs this fix sooner, we should add it to 1.13.3
milestone: NEEDS_TRIAGE => SSSD 1.13.3
owner: somebody => lslebodn
Lukas is still looking into the issue, moving to 1.13.4
milestone: SSSD 1.13.3 => SSSD 1.13.4
patch: 0 => 1
status: new => assigned
resolution: => fixed
status: assigned => closed
Metadata Update from @jhrozek:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.13.4
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:
If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.
Thank you for understanding. We apologize for all inconvenience.
to comment on this ticket.