SSSD / sssd

#329 Explicit timeout=0 value for a domain causes tight loop
Closed: Fixed Opened by sgallagh.

Closed: Fixed
Reopen Issue

The man page cites 'timeout = 0' as being 'no timeout'. In reality, if it's unspecified, we actually set a default timeout (10s), but if it's explicitly set to 0, we actually tight-loop ourselves checking for the service (and are never available to answer the connection request).

We should make 'timeout = 0' default to the configured timeout and update the manpage to reflect this.

Fields changed

owner: somebody => sgallagh
status: new => assigned

Fixed by 860d9f273e36ffb69f16377949b8ba9444ac99bf

fixedin: => 1.0.0
resolution: => fixed
status: assigned => closed

Man page has been updated for default value of 10 - but tight loop is still there when set to 0.[[BR]]
Version[[BR]]
sssd-1.0.0-0.2009121516gitdf6d168.fc11.i586

proposed: =>
resolution: fixed =>
status: closed => reopened

Fixed by b8fdafa3b553592a683b8eb657d8a7bdb129673e

Didn't catch both cases where a tight loop could occur.

resolution: => fixed
status: reopened => closed

Need to update the User Guide as well as the man page.

doc: 0 => 1

Doc fixed.

Fields changed

docupdated: 0 => 1

Fields changed

coverity: =>
patch: => 0
tests: 1 => 0
upgrade: => 0

Fields changed

rhbz: => 0

Metadata Update from @sgallagh:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.0

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/1371

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.
Metadata
None
None
None
Low
defect
SSSD
0.99.1
rcrit
0
0
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.