Non-existent i18n files lead to needless server failover
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt-cacher (Debian) |
Fix Released
|
Unknown
|
|||
apt-cacher (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: apt-cacher
I have an apt-cacher setup in which the main path_map element lists two servers, in the following order:
ubuntu.
us.
I.e. a random mirror server, and the official Ubuntu US archive server.
Yesterday (April 23), I invoked "apt-get update" on a system pointed at this apt-cacher server, and inexplicably, it hung while downloading the first Translation-
Half an hour of investigation later, I found the problem. There are two things going on here:
1. There is no Translation-en_US file. It is not present (e.g. for the Jaunty main repository) in either of
http://
http://
apt-cacher fails to find the file at the first location, so it tries the second one, and when that turns up nothing it gives up (and so does apt-get, continuing on to the next file).
2. The US archive server is, of course, being completely hammered by the release of Jaunty on the 23rd. It is taking an unusually long time to respond to even minor HTTP requests.
Indeed, if I run "apt-get update" with LANG=C, then no i18n files are downloaded, and the whole update procedure breezes through like it usually does.
So it seems to me that this is a corner case that apt-cacher ought to handle more gracefully. There was no need for apt-get to hang while updating; no need for apt-cacher to fail over to another server for a file that need not exist (as opposed to, say, a package file, whose non-existence would necessarily be an error). Addressing this behavior would not only make updating on release day feasible, it would also make updating on other days faster, and reduce 404s on the archive server, as the needless failover could be avoided altogether.
Changed in apt-cacher (Debian): | |
status: | Unknown → Fix Committed |
Changed in apt-cacher (Debian): | |
status: | Fix Committed → Fix Released |
I can't tell if these are exactly the same, but this sounds similar to Debian bug 517761: http:// bugs.debian. org/cgi- bin/bugreport. cgi?bug= 517761