FS#15369 - Pacman should timeout when mirror is not responding
Attached to Project:
Pacman
Opened by Tomas Mudrunka (harvie) - Saturday, 04 July 2009, 14:42 GMT
Last edited by Dave Reisner (falconindy) - Monday, 22 August 2011, 02:26 GMT
Opened by Tomas Mudrunka (harvie) - Saturday, 04 July 2009, 14:42 GMT
Last edited by Dave Reisner (falconindy) - Monday, 22 August 2011, 02:26 GMT
|
Details
Summary and Info:
When pacman repository is droping incomming connections insted of refusing them, or if the server is just tooooooo much overloaded or even down, pacman will stuck forever (which is not good when launching it from cron, etc...). Pacman should have some timeout (eg. ~20 seconds - like web browsers do). It is not problem when it timeouts, because it can continue to the next mirror (like when connection is properly refused by mirror). Steps to Reproduce: 1.) Set pacman to use some non-existing IP (non-respondning server) as mirror 2.) pacman -Sy (or -Syuw) I had this problem yesterday, when my local mirror was not responding properly and pacman (-Syuw from cron) wasn't trying another mirrors, but it was just locked in background and i was forced to kill it each time i wanted to work with pacman. Thanks. |
This task depends upon
Closed by Dave Reisner (falconindy)
Monday, 22 August 2011, 02:26 GMT
Reason for closing: Implemented
Additional comments about closing: See comments
Monday, 22 August 2011, 02:26 GMT
Reason for closing: Implemented
Additional comments about closing: See comments
error: failed retrieving file 'dragonlord.db.tar.gz' from repo.dragonlord.cz : Connection timed out
The new pacman 3.3 just stops at the repo and waits forever.
"timeout.tv_sec += fetchTimeout;"
This suggests me that we should add sec instead of microsec.
http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=14a93b2e436ed19c814653c3b2b61605fd5ca156
and from man connect :
If the connection cannot be established immediately and O_NONBLOCK is not set for the file descriptor for the socket, connect() shall block
for up to an unspecified timeout interval until the connection is established.
"unspecified timeout interval"... very useful...
I tested as said in the original report, by using a random IP :
Server = ftp://129.34.123.2
Do you get different results?
"This is not a bug, it is normal TCP/IP behavior. If you really insist on
knowing better, you can use an alarm timer and mark the signal as
non-restart. The connect will fail and continue to the next socket.
Joerg"
- the issue is still not fixed.
- Timeouts are good: having pacman error out after a certain period is much more friendly towards humans and scripts.
- pacman is a package manager, not a tcp/ip library
- Dan is in favor of fixing this.
- the issue is still not fixed.
- Timeouts are good: having pacman error out after a certain period is much more friendly towards humans and scripts.
- pacman is a package manager, not a tcp/ip library
- Dan is in favor of fixing this.
Heh, that's exactly why I closed this bug. pacman is not a tcp/ip library, and I did not insist I knew better than tcp/ip behavior.
Timeouts are obviously good and friendly, nothing to argue here :)
It will also be interesting to see how this can be fixed, if just by implementing what Joerg said works, and how that can be implemented.
This affects not only C, but also Scripting languages like PERL or PHP.
I've used ugly hack to workaround this. You can fopen() pipe to netcat or curl and handle it in non-blocking manner, but it's IMHO really ugly and can be done somehow nicer (using separate threads or something...)
As long as these issues are not fixed, the installation procedure exposes various bugs as well. (
FS#16277andFS#19342, although the latter might be a different issue)and pacman more or less instantly return the error;
but if i append Server = http://xyz.xyz.xyz.xyz/$repo/os/x86_64
pacman wait and not time out .....
so the bug is still here (pacman-3.4.3-1)
Connections which fail to reach a speed of 1024 bytes/second for 10 seconds will error out.