Bug 1464149 - Don't apply 'retries=' option to tcp timeouts
Don't apply 'retries=' option to tcp timeouts
Status: NEW
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-06-22 10:10 EDT by Pavel Raiskup
Modified: 2017-06-27 02:39 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pavel Raiskup 2017-06-22 10:10:51 EDT
Looks like it means basically reverting of:

Effectively, if there are some networking issues (which happens just now
internally for one server hosting a lot of package repositories), dnf
re-tries downloading from timeout'ing servers.

Having N repositories from such server means (N x retries x timeout)
delay, which makes dnf totally unusable for a lot of internal customers.  Even
when we have set skip_if_unavailable=True.
Comment 2 Pavel Raiskup 2017-06-27 02:39:06 EDT
Ah, the retries= option is applied on timeouts only in yum -- that's good

Though dnf doesn't perform well neither in this case.  At least there
seems to be default timeout of 2 minutes for repository download.  Not
having repo downloading in parallel, dnf hangs for 2*N minutes for N
repositories from one server (can be simulated by iptables -I OUTPUT -d
<IP> -j DROP).  Seems like bug 1210325, so I reopened it.

Except for parallelizing, dnf could special case the downloads where no
single byte was downloaded for much shorter timeout.. Would that make sense?

Note You need to log in before you can comment on or make changes to this bug.