[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531 Shengjing Zhu changed: What|Removed |Added CC||zsj950618 at gmail dot com --- Comment #5 from Shengjing Zhu --- Created attachment 13308 --> https://sourceware.org/bugzilla/attachment.cgi?id=13308&action=edit debuginfod verbose output -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531
--- Comment #6 from Shengjing Zhu ---
I'm the one that has complained "Timer expired" error when using
https://debuginfod.debian.net. Sergio points me this issue one week ago.
The problem is that I have a bad connection to the server. Log is attached with
DEBUGINFOD_VERBOSE=1.
url 0
https://debuginfod.debian.net/buildid/75703faf54dc0d3014ce34c9ce110eb6fe217818/debuginfo
query 1 urls in parallel
Downloading separate debug info for
/lib/x86_64-linux-gnu/libapt-private.so.0.0...
committed to url 0
server response Timeout was reached
url 0 Operation too slow. Less than 102400 bytes/sec transferred the last 90
seconds
not found Timer expired (err=-62)
Download failed: Timer expired. Continuing without debug info for
/lib/x86_64-linux-gnu/libapt-private.so.0.0.
$ curl -v
https://debuginfod.debian.net/buildid/75703faf54dc0d3014ce34c9ce110eb6fe217818/debuginfo
-o /dev/null
{ [5 bytes data]
100 2700k 100 2700k0 0 20137 0 0:02:17 0:02:17 --:--:-- 24550
* Connection #0 to host debuginfod.debian.net left intact
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531 --- Comment #7 from Frank Ch. Eigler --- OK, it looks like four separate instances of "Timer expired (err=-62)" errors, indicating that the system did wait the 90 seconds (each time). Doing a retry on our own initiative after this would be possible but would cause more elapsed time. Have you considered setting $DEBUGINFOD_TIMEOUT to a larger value, like 180 or 300? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531 --- Comment #8 from Shengjing Zhu --- Created attachment 13309 --> https://sourceware.org/bugzilla/attachment.cgi?id=13309&action=edit large timeout output -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531 --- Comment #9 from Shengjing Zhu --- With large timeout it works. I paste the log with timestamp in attachment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531 --- Comment #10 from Frank Ch. Eigler --- OK, for your use case, a retry possibly would not help, but an enlarged timeout does. Interesting. Should we keep this RFE open or close it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27531] Support retry of failed downloads
https://sourceware.org/bugzilla/show_bug.cgi?id=27531 --- Comment #11 from Sergio Durigan Junior --- Up to you. I think a retry mechanism is an interesting thing to have, even if it's not used much nor enabled by default. But I understand there are higher priorities now. -- You are receiving this mail because: You are on the CC list for the bug.
