[Apt-cacher-ng-users] apt-cacher returns error 503, apt-get doesn't retry
Arnaud
arnaud at preev.io
Sat Apr 15 16:27:23 UTC 2017
Hi Eduard,
thanks for your reply, and sorry for the long delay.
I didn't have time to work on that topic anymore, so I have little
feedback to give you.
On 03/18/2017 03:19 AM, Eduard Bloch wrote:
>
>> My current attempt to improve the situation is simply to run apt-get
>> with the option `-oAcquire::Retries=1`, for example. However, I don't
>> get the expected behavior.
>>
>> If I run apt-get WITHOUT apt-cacher, I clearly see apt-get retrying,
>> showing that I'm doing it right. The logs look like that:
>>
>> Err http://ftp.us.debian.org/debian/ jessie/main htop amd64 1.0.3-1
>> Could not resolve 'ftp.us.debian.org'
>> Err http://ftp.us.debian.org/debian/ jessie/main htop amd64 1.0.3-1
>> Could not resolve 'ftp.us.debian.org'
> What does "retrying" mean here? I guess it's trying to get the Release
> file instead of InRelease because the later failed.
Retrying means that the message "Err http://..." appears as many times
as the value of "-oAcquire::Retries" + 1. So if I put "Retries=10", I'll
see the message 11 times. It means to me that there's some kind of
retrying happening somewhere.
As for the files "Release" or "InRelease" that you mention, I don't know
really.
>> E: Failed to fetch
>> http://ftp.us.debian.org/debian/pool/main/h/htop/htop_1.0.3-1_amd64.deb
>> Could not resolve 'ftp.us.debian.org'
>>
>> If I run apt-get WITH apt-cacher, apt-get doesn't retry though. The logs
>> look like that.
>>
>> Err http://ftp.us.debian.org/debian/ jessie/main htop amd64 1.0.3-1
>> 503 DNS error for hostname ftp.us.debian.org: Name or service not
>> known. If ftp.us.debian.org refers to a configured cache repository,
>> please check the corresponding configuration file.
>> E: Failed to fetch
>> http://ftp.us.debian.org/debian/pool/main/h/htop/htop_1.0.3-1_amd64.deb
>> 503 DNS error for hostname ftp.us.debian.org: Name or service not
>> known. If ftp.us.debian.org refers to a configured cache repository,
>> please check the corresponding configuration file.
> How is the client configuration? Set as proxy? Then it would be not a
> network error but a remote server error, which might be handled
> differently by apt.
I use the environment variable "http_proxy=http://127.0.0.1:3142".
As for the error here, I was just trying to check if apt-cacher-ng had
any influence on the retry option. So my (naive) approach at this time
was just to turn off the WiFi on my laptop, then run the "apt update"
command and witness it retrying. When I unset "http_proxy", apt retries,
and when I set "http_proxy", it doesn't. That's why I got in touch with you.
In real-life, I'm dealing with bad network conditions. I'm living in
Vietnam and the network was really congested lately, due to damaged
undersea cables, and leading to sluggish network with unpredictable
failures. I thought I could manage with the "Retry" option of apt, but
in the end I think it's the wrong approach. Because depending on the
kind of network failure, I realize that the request might fail
immediately, so apt can exhaust its 20 retries in a second...
Anyway. I couldn't reproduce the particular scenario I copy/pasted here.
Furthermore, I have some other ways to workaround this situation, so I
won't bother you with that anymore, just forget about it. If ever I have
time to dig into this topic again, and have some question regarding
apt-cacher-ng, I'll get back in touch, with hopefully something a bit
more detailed, and more precise questions.
Best regards,
Arnaud
More information about the Apt-cacher-ng-users
mailing list