cargo
cargo copied to clipboard
Cargo update / install: error reading from the zlib stream; class=Zlib (5)
Problem
Trying to run cargo update for a project or cargo install now produces this error:
warning: spurious network error (2 tries remaining): error reading from the zlib stream; class=Zlib (5)
warning: spurious network error (1 tries remaining): error reading from the zlib stream; class=Zlib (5)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`
Caused by:
error reading from the zlib stream; class=Zlib (5)
Fails on versions:
cargo 1.58.0 (7f08ace4f 2021-11-24)
and
cargo 1.60.0-nightly (06b9d3174 2022-01-11)
Although I suspect it has to do with the OS. Unfortunately the OS can not be upgraded at this time.
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
cargo 1.58.0 (7f08ace4f 2021-11-24)
release: 1.58.0
commit-hash: 7f08ace4f1305de7f3b1b0e2f765911957226bd4
commit-date: 2021-11-24
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: OracleLinux 7.9.0 [64-bit]
Can you clone https://github.com/rust-lang/crates.io-index
using git directly? If so, does Cargo work if you set CARGO_NET_GIT_FETCH_WITH_CLI
?
Yes and yes, that works. Thanks!
@jguhlin Is this still a problem if you don't use CARGO_NET_GIT_FETCH_WITH_CLI
? Or was this some transient issue?
@ehuss Wanted to test it, and I'm still having the problem when CARGO_NET_GIT_FETCH_WITH_CLI is turned off. I even did a rustup update to grab all new versions.
If you'd like to help us debug this, can you try running with the environment variables CARGO_HTTP_DEBUG=true
and CARGO_LOG=cargo::ops::registry=trace
set? That should display some debug information about the network traffic. It might help illuminate what's going wrong.
Sure thing. Will throw in the system specs (it's only on two of our servers, not on my workstation or home PC).
❯ cargo --version
cargo 1.59.0 (49d8809dc 2022-02-10)
❯ CARGO_HTTP_DEBUG=true CARGO_LOG=cargo::ops::registry=trace cargo update 2> cargo_update.log
❯ cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.9:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.9
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.9"
❯ openssl version
OpenSSL 1.1.1m 14 Dec 2021
It looks like you are using a proxy (iaa-proxy.uod.otago.ac.nz), was that intentional? Do you happen to know what software it is running? You can try setting the CARGO_HTTP_MULTIPLEXING=false
environment variable. I seem to recall that some proxies have issues with http/2.
Yeah, the server requires a proxy unforttunately, so I have it set as an environment variable. If I unset the variable I get the same error.
Comes up with the same error with just that env variable.
❯ CARGO_HTTP_MULTIPLEXING=false cargo update
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package: /Volumes/archive/deardenlab/guhlin/development/sfasta/libsfasta/Cargo.toml
workspace: /Volumes/archive/deardenlab/guhlin/development/sfasta/Cargo.toml
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package: /Volumes/archive/deardenlab/guhlin/development/sfasta/sfa/Cargo.toml
workspace: /Volumes/archive/deardenlab/guhlin/development/sfasta/Cargo.toml
Updating crates.io index
warning: spurious network error (2 tries remaining): error reading from the zlib stream; class=Zlib (5)
warning: spurious network error (1 tries remaining): error reading from the zlib stream; class=Zlib (5)
error: failed to get `ahash` as a dependency of package `libsfasta v0.0.1 (/Volumes/archive/deardenlab/guhlin/development/sfasta/libsfasta)`
I ran into this on GitHub actions with 1.45.0. Judging by some folks referencing this issue, that seems to happen on Github actions quite a bit now.
This issue is resolved for me in the newest cargo (updated today, 9 Sept 2022). Probably was fixed before that, but just adding the date as a point of reference.
This issue has returned for cargo fetching remote git repos in cargo 1.78.0. The same environment fix still works, but no idea why it has returned. I suspect because the OS is older?
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.9:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.9
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.9"
Linux biochemcompute3.uod.otago.ac.nz 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
@jguhlin Would you mind git-bisect it so we can learn what's wrong?
@weihanglo I'm not sure how to run that in a useful way. It seems to be working on the server again for me, so it could be a strange proxy issue or perhaps they've updated something.