Bug 1109189
| Summary: | connection timeouts on slow lines | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thorsten Leemhuis <fedora> |
| Component: | librepo | Assignee: | Ales Kozumplik <akozumpl> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | akozumpl, fedora, felip_assis, jzeleny, pnemade, rholy, tim.lauridsen, tmlcoch |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | librepo-1.7.4-3.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-30 10:31:11 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Thorsten Leemhuis
2014-06-13 12:33:07 UTC
Hello, thank you for the report. We'll take a look. Thorsten, I'm not able to reproduce this using "http://repos.fedorapeople.org/repos/thl/kernel-vanilla-mainline/fedora-20/x86_64/", neither have I heard of other people having problems with fedorapeople.org repos and use few myself. Can you try without the transparent proxy and report the results? Thank you. Hmm, digging deeper I see that librepo sets CURLOPT_LOW_SPEED_TIME to 10 seconds and CURLOPT_LOW_SPEED_LIMIT to 1000. CCing the librepo maintainer. Tomas, could it be the time to bump the default values? Ta'. Alternative is re-enabling the 'minrate' and 'timeout' options from Yum. A quick comment while we wait for a reply from Tomas (In reply to Ales Kozumplik from comment #2) > I'm not able to reproduce this […] using fedorapeople.org repos […] Just for clarifiction: It works fine for me most of the time, too; maybe 95 to 98 % of the time, which is not bad, but not really satisfiying I'd say. > Can you try without the transparent proxy and report the results? No, sorry, no way around it here at work, where I've seen the problem most of the time. But I saw it at home, too (no proxy there). It just happens seldomly and is not easy to reproduce; calling dnf again often is enough to work around it. No worries, after I saw how librepo sets up curl it is easily explainable on the DNF side. I'm just curious whether we can get away by tweaking the defaults or need to have the manual setting. Hi, I can definitely increase the default CURLOPT_LOW_SPEED_TIME, what would you say to 30sec (or maybe 60sec)? - I think this could be reasonable amount of time. Also, I can reduce the default CURLOPT_LOW_SPEED_LIMIT but I am not sure if it is really necessary, because 1000 bytes per second, which is the current default value, seems to be already pretty low to me. Moreover, the librepo sets CURLOPT_CONNECTTIMEOUT to only 30sec which also can be source of this troubles (I just found out that there is a bug in the documentation of librepo which says that the default CONNECTTIMEOUT value is 300sec). So I can also increase this value. To my defense, all current values were chosen in order to provide maximal user comfort: low connect_timeout = quickly skip non-working mirrors, low low_speed_time - quickly skip slow mirrors. But obviously, the values have to be slightly tweaked. (In reply to Tomas Mlcoch from comment #6) > To my defense, all current values were chosen in order to provide maximal > user comfort: low connect_timeout = quickly skip non-working mirrors, low > low_speed_time - quickly skip slow mirrors. But obviously, the values have > to be slightly tweaked. Hmmm. Maybe it makes sense to have a codepath with different settings in case there is only one server (or only one left after trying multiple ones)? (In reply to Tomas Mlcoch from comment #6) > Hi, > > I can definitely increase the default CURLOPT_LOW_SPEED_TIME, what would you > say to 30sec (or maybe 60sec)? - I think this could be reasonable amount of > time. I think 30s would be a great start. > > Also, I can reduce the default CURLOPT_LOW_SPEED_LIMIT but I am not sure if > it is really necessary, because 1000 bytes per second, which is the current > default value, seems to be already pretty low to me. > That's really quite low already, let's not move this one. Moving to you, thanks. librepo-1.7.4-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/librepo-1.7.4-3.fc20 Package librepo-1.7.4-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing librepo-1.7.4-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7793/librepo-1.7.4-3.fc20 then log in and leave karma (feedback). librepo-1.7.4-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. FWIW, a quick comment: I'm not sure if this is fixed for real, as I ran into the issue today yet again: """ Cannot download kernel-devel-3.16.0-0.rc3.git0.1.vanilla.mainline.knurd.1.fc20.x86_64.rpm: All mirrors were tried "" (that's a package from http://repos.fedorapeople.org yet again) This is with librepo-1.7.4-3.fc20.x86_64. It worked on the second try, but it makes me really suspcious that I ran into this again so soon... |