Binary package hint: apt
As part of testing, I am occasionally installing large packages from private-ppas on launchpad, which makes use of https and apt-transport-https. While doing so, I get timeouts like the following:
Get:1 https://private-ppa.launchpad.net hardy/main PACKAGE 9.1.0-6 [63.4MB]
Err https://private-ppa.launchpad.net hardy/main PACKAGE 9.1.0-6
Operation timed out after 120000 milliseconds with 13942784 out of 63370760 bytes received
Failed to fetch https://ID:<email address hidden>/PROJECT/ubuntu/pool/main/P/PACKAGE/PACKAGE_9.1.0-6_i386.deb Operation timed out after 120000 milliseconds with 13942784 out of 63370760 bytes received
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Manually wget'ing the package and installing succeeds, and I also do not see similar timeouts when downloading (asbsurdly) large packages over http.
Looking at the source code, in methods/https.cc we have the following code:
// set timeout
int timeout = _config->FindI("Acquire::http::Timeout",120);
curl_easy_setopt(curl, CURLOPT_TIMEOUT, timeout);
curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, timeout);
Quoting the curl_easy_setopt(3) manpage:
CURLOPT_TIMEOUT
Pass a long as parameter containing the maximum time in seconds
that you allow the libcurl transfer operation to take.
Note that it's not a timeout of inactivity, it's just a maximum time the transfer can take. This does not match the behavior of method/http.cc where HttpMethod::Go sets the same timeout value on a select() call on any of the open filedescriptors; this only gets triggered if none of the connections make any progress by the timeout time.
It seems to me that the http and https behaviors ought to be made consistent, or else the https method ought to honor a separate Acquire::https::Timeout setting.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: apt-transport-https 0.7.20.2ubuntu5
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: apt
Uname: Linux 2.6.28-11-generic i686
Ran into this bug at UDS. Caused me quite a bit of trouble; it seems the issue is that http and https work differently with the same options applied based off the Debian bug.