Bug 1272977
Summary: | dnf waits 10 minutes for a single repo (for unresponsive ftp server?) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||
Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 23 | CC: | jsilhan, mluscon, packaging-team-maint, pnemade, tmlcoch, vmukhame | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | dnf-1.1.8-1.fc24 dnf-1.1.8-1.fc23 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-04-13 07:22:15 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: | |||||||
Attachments: |
|
Description
Kamil Páral
2015-10-19 10:38:55 UTC
Created attachment 1084330 [details] dnf.iibrepo.log Don't forget to unwrap comments when reading comment 0. Here is dnf.librepo.log output, but since there are no timestamps, I have no idea which parts are relevant. I tried to pick a part I think is relevant. Hi Tomas, is there any librepo timeout option which DNF should use to prevent this? Hi Michal, there are few. The most important one is LRO_CONNECTTIMEOUT [1]. Another ones are LRO_LOWSPEEDTIME [2] and LRO_LOWSPEEDLIMIT [3]. Default timeout value for connection phase (LRO_CONNECTTIMEOUT) is currently set to 120sec. 10min timeout is a really big number. From what I see, dnf is using: current_timeout = h.getinfo(librepo.LRO_CONNECTTIMEOUT) h.connecttimeout = max(self.timeout, current_timeout) Maybe the self.timeout in dnf contains a higher value than librepo and thus the higher timeout is used? An idea, is it possible to set the connection timeout value to dnf manually via dnf.conf? Could be the higher timeout hard-coded in Kamil's and Jiri's configs? (I know this is very unlikely, but worth to check) Also, if the value could be set by user, it may worth to try to set there manually some small value (e.g. 10sec) and then try to reproduce the issue. Would you be willing to try that once you are at VUT FIT again, Kamil? [1] http://rpm-software-management.github.io/librepo/lib.html#librepo.LRO_CONNECTTIMEOUT [2] http://rpm-software-management.github.io/librepo/lib.html#librepo.LRO_LOWSPEEDTIME [3] http://rpm-software-management.github.io/librepo/lib.html#librepo.LRO_LOWSPEEDLIMIT The default timeout values currently used by DNF are: h.lowspeedlimit = 1000 h.lowspeedtime = 120 h.connecttimeout = max(120, librepo.LRO_CONNECTTIMEOUT) librepo.LRO_CONNECTTIMEOUT seems to be set to 18 by default, any idea why? If I add timeout=1 into my dnf conf, I get: Error: Failed to synchronize cache for repo 'updates' from 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f22&arch=x86_64': Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f22&arch=x86_64 [Connection timed out after 1001 milliseconds] (In reply to Tomas Mlcoch from comment #3) > Could be the higher timeout hard-coded in Kamil's and Jiri's > configs? (I know this is very unlikely, but worth to check) Nope :) > Also, if the value could be set by user, it may worth to try to set there > manually some small value (e.g. 10sec) and then try to reproduce the issue. > Would you be willing to try that once you are at VUT FIT again, Kamil? That's a great suggestion. Unfortunately I don't go there very often, and it seems they already fixed their ftp server (now they work fine). I wonder if there's a way to emulate this? (an ftp server which doesn't respond). librepo.LRO_CONNECTTIMEOUT == 18 is ok as it is just a constant for usage in Handle.setopt() method [1]. But there is a problem. Dnf is using: current_timeout = h.getinfo(librepo.LRO_CONNECTTIMEOUT) which is not right, "LRO_" prefixed constants should be used only in Handle.setopt(), for Result.getinfo() there are "LRI_" prefixed constants [2]. LRO_ and LRI_ lists weren't designed 1:1 because Result object can contain extra info (from the downloading etc.), for example LRI_MIRRORS which returns list of mirrors built from urls specified by LRO_URLS and urls obtained from metalink and/or mirrorlists. librepo.LRO_CONNECTTIMEOUT == 18 == librepo.LRI_FASTESTMIRROR so the line in dnf doesn't obtain a timeout set in librepo but value 0 or 1 whether fastest mirror build-in functionality is enabled or disabled (it is disabled default == 0). Currently there is no way in librepo how to get connecttimeout. Moreover, I think that intended construction: h.connecttimeout = max(self.timeout, current_timeout) is incorrect. It means that when a user specifies lower timeout than handle already has, user's timeout is going to be ignored and handle's value is going to be preserved. IMHO, the correct approach should be: if self.timeout: h.connecttimeout = self.timeout (This probably isn't the case of the 10min timeout, but definitely a bug) The fail you see when you set timeout to 1sec just means that librepo wasn't able to finish connect phase in the 1sec (1000ms) you have specified, which looks sane, 1sec for connection phase is low value. [1] http://rpm-software-management.github.io/librepo/lib.html#handle-options [2] http://rpm-software-management.github.io/librepo/lib.html#handle-info-options Kamil, I'll try to emulate a FTP server that accepts SYN but hesitate to return SYN-ACK packets :) Today, I had connection issues with source of one repo. I had to wait for connection timeout which occurred, exactly as expected, after 120sec. Log: ---- 08:35:11 Librepo version: 1.7.17 with CURL_GLOBAL_ACK_EINTR support (libcurl/7.40.0 NSS/3.20 Basic ECC zlib/1.2.8 libidn/1.32 libssh2/1.5.0) ...SNIP... 08:38:23 prepare_next_transfer: URL: http://XXX/fedora/22/repodata/repomd.xml ...SNIP... 08:40:23 check_transfer_statuses: Transfer finished: repodata/repomd.xml (Effective url: http://XXX/fedora/22/repodata/repomd.xml) 08:40:23 check_finished_transfer_status: Serious error - Curl code (28): Timeout was reached for http://XXX/fedora/22/repodata/repomd.xml [Connection timed out after 120004 milliseconds] ...SNIP... (In reply to Tomas Mlcoch from comment #8) > Today, I had connection issues with source of one repo. I had to wait for > connection timeout which occurred, exactly as expected, after 120sec. I've seen the 2 minute timeout many times, it's working as expected. So that's why I was very much surprised of a 10 minute timeout in certain cases, and why I reported this bug. So yeah, I see the 2 minute timeout in most cases too. dnf-plugins-core-0.1.20-1.fc24 dnf-1.1.8-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5dae5d2add dnf-1.1.8-1.fc23 dnf-plugins-core-0.1.20-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ddeabfcfe6 dnf-1.1.8-1.fc24, dnf-plugins-core-0.1.20-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5dae5d2add dnf-1.1.8-1.fc24, dnf-plugins-core-0.1.20-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. dnf-1.1.8-1.fc23, dnf-plugins-core-0.1.20-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ddeabfcfe6 dnf-1.1.8-1.fc23, dnf-plugins-core-0.1.20-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |