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#71073 - Race condition when mirrors use HTTP/2

Attached to Project: Pacman
Opened by Morten Linderud (Foxboron) - Monday, 31 May 2021, 19:29 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 31 May 2021, 21:43 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 6.0.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

I'm not sure if HTTP/2 is the symptom or the cause of the issue. But when talking with mirrors publishing over HTTP/2 on TLS (443) pacman reports an error:

HTTP/2 stream 0 was not closed cleanly before end of the underlying stream

This occurs for each repository, however which repository and if there is an error at all is random.

# pacman -Syu
[...]
error: failed retrieving file 'extra.db' from mirror.archlinux.no :
error: failed retrieving file 'multilib-testing.db' from mirror.archlinux.no : HTTP/2 stream 0 was not closed cleanly before end of the underlying stream

# pacman -Syu
[...]
error: failed retrieving file 'community-testing.db' from mirror.archlinux.no : HTTP/2 stream 0 was not closed cleanly before end of the underlying stream
error: failed retrieving file 'multilib.db' from mirror.archlinux.no : HTTP/2 stream 0 was not closed cleanly before end of the underlying stream

Note that the mirrors where reported as "up to date" before the error.

This error disappears when you select a mirror without HTTP/2 it seems.

Steps to Reproduce:

* Use a HTTP/2 mirror

* Use `pacman -Syu`.


Note it seems to be racey and it's not guaranteed that just using a HTTP/2 enabled mirror produces an error. Allan tried :)

Medium severity as it *seems* like it doesn't affect any upgrade functionality. It's just an error.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 31 May 2021, 21:43 GMT
Reason for closing:  Not a bug
Additional comments about closing:  OP request: this is a bug in nginx which is now fixed upstream and can also be worked around in the mirror server's nginx config.
Comment by Morten Linderud (Foxboron) - Monday, 31 May 2021, 21:17 GMT
This issue occurs with faulty configured http/2 webservers where keepalive_timeout is set to 0 which enables faulty behavior in nginx.

https://trac.nginx.org/nginx/ticket/2142

This issue was fixed with the upstream mirror.

Loading...