Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#23690 - make libfetch timeout configurable

Attached to Project: Pacman
Opened by Taimon (Taimon) - Monday, 11 April 2011, 07:54 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 22 April 2012, 13:19 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Very Low
Priority Normal
Reported Version 3.5.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
When I'm on a low bandwidth link (56k Modem) and try to download something via pacman (libfetch) the download is aborted after ~200 KiB and I have to repeat the command. Some debugging revealed that libfetch sends a ETIMEDOUT and setting fetchTimeout to 0 or something like 30 solves the problem for me.

Steps to Reproduce:
Kinda hard to reproduce because it most likely depends on my modem driver (martian) and modem. Sometimes the download seems to halt temporarily but a short time afterwards it continues with increased speed. (i.e. it stops at 200 KiB but after 10 seconds it immediatly jumps to 300 KiB.)
I guess this is why I'm getting the timeout.
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 22 April 2012, 13:19 GMT
Reason for closing:  Fixed
Comment by Dan McGee (toofishes) - Monday, 11 April 2011, 16:27 GMT
We're not using libfetch after the 3.5.X series, so we're unlikely to change anything before 3.6.X and the new libcurl code. Anything we can (if we should at all?) do there?
Comment by Taimon (Taimon) - Tuesday, 12 April 2011, 05:13 GMT
As far as I'm concerned you don't need to change anyting. I'll just continue LD_PRELOADing my libalpm until 3.6 arrives.
Maybe you can give me a rough ETA?
Comment by Dave Reisner (falconindy) - Thursday, 26 May 2011, 00:15 GMT
This will be fixed with 3.6 with curl's CURLOPT_LOW_SPEED_LIMIT and CURLOPT_LOW_SPEED_TIME. We can declare a transfer as dead if the instantaneous transfer rate drops below SPEED_LIMIT bytes per second for more than SPEED_TIME seconds.
Comment by Dan McGee (toofishes) - Wednesday, 01 June 2011, 21:33 GMT
I suppose we could bump this to say, 15 seconds? 50% larger than the 10 sec we currently use at least. Or would that not help?
Comment by Allan McRae (Allan) - Sunday, 22 April 2012, 10:51 GMT
@Dave: I'm sure I have seen the slow download timeout with 4.0... So this is fixed?
Comment by Dave Reisner (falconindy) - Sunday, 22 April 2012, 13:19 GMT
Well this isn't configurable, but it's a lot better than what did libfetch (block forever).

Loading...