git clone "error: RPC failed; curl 56 Failure when receiving data from the peer"

[Balkoth]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.47.0.windows.2
cpu: x86_64
built from commit: 1f8a83cba6e88fad4b881885e64cfb89458e3653
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.10.1
OpenSSL: OpenSSL 3.2.3 3 Sep 2024
zlib: 1.3.1

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19045.5011]
(c) Microsoft Corporation. Alle Rechte vorbehalten.

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCode
Custom Editor Path: 
Default Branch Option:  
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Repository is hosted on a Server with git-http-backend.exe

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash/CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git clone https://server.company.de/Repository.git

• What did you expect to occur after running these commands?

Cloning without errors.

• What actually happened instead?

Cloning into 'Repository'...
remote: Enumerating objects: 19174, done.
remote: Counting objects: 100% (19174/19174), done.
remote: Compressing objects: 100% (2168/2168), done.
error: RPC failed; curl 56 Failure when receiving data from the peer
remote: Total 19174 (delta 18267), reused 17491 (delta 16998), pack-reused 0 (from 0)
Receiving objects: 100% (19174/19174), 6.83 MiB | 4.74 MiB/s, done.
Resolving deltas: 100% (18267/18267), done.
Updating files: 100% (2589/2589), done.

I don't know where to start because the error message is unhelpful.

Randomly setting

   [http]
       postBuffer = 524288000

on the client and server has had no effect.

Setting GIT_HTTP_MAX_REQUEST_BUFFER to 100M from default 10M has no effect.

GIT_CURL_VERBOSE=1 does not reveal any helpful information to me.

A shallow clone works without error:

$ git clone --depth=1 https://server.company.de/Repository.git
Cloning into 'Repository'...
remote: Enumerating objects: 2630, done.
remote: Counting objects: 100% (2630/2630), done.
remote: Compressing objects: 100% (2294/2294), done.
remote: Total 2630 (delta 2369), reused 388 (delta 334), pack-reused 0 (from 0)
Receiving objects: 100% (2630/2630), 1.48 MiB | 21.72 MiB/s, done.
Resolving deltas: 100% (2369/2369), done.
Updating files: 100% (2589/2589), done.

[jblaine]

We are seeing the same thing:

$ git clone https://github.com/google/googletest.git/
Cloning into 'googletest'...
remote: Enumerating objects: 27711, done.
remote: Counting objects: 100% (60/60), done.
remote: Compressing objects: 100% (43/43), done.
error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0
remote: Total 27711 (delta 24), reused 32 (delta 12), pack-reused 27651 (from 1)
Receiving objects: 100% (27711/27711), 13.04 MiB | 6.50 MiB/s, done.
Resolving deltas: 100% (20568/20568), done.

Adding --depth=1 causes the failure to go away.

Install options

Editor Option: VIM
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

$ git --version --build-options
git version 2.45.1.windows.1
cpu: x86_64
built from commit: 965b16798dab6962ada5b0d8cf0dca68f385c448
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

Microsoft Windows [Version 10.0.19045.5131]
(c) Microsoft Corporation. All rights reserved.

[dscho]

error: RPC failed; curl 56 Failure when receiving data from the peer

This error looks a bit different than

error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0

though.

In any case, maybe switching to the Secure Channel backend via git config http.sslBackend schannel helps?

[Balkoth]

On my client and server this is already in the C:\Program Files\Git\etc\gitconfig:

Client:

[diff "astextplain"]
	textconv = astextplain
[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
[http]
	sslBackend = schannel
[core]
	autocrlf = false
	fscache = true
	symlinks = true
	pager = tr -d '\\r' | less -REX
	editor = \"C:\\\\Program Files\\\\Microsoft VS Code\\\\bin\\\\code\" --wait
[pull]
	rebase = false
[credential]
	helper = manager
[credential "https://dev.azure.com"]
	useHttpPath = true
[init]
	defaultBranch = master
[safe]
	directory = *

Server:

[diff "astextplain"]
	textconv = astextplain
[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
[http]
	sslBackend = schannel
[core]
	autocrlf = false
	fscache = true
	symlinks = false
	editor = \"C:\\\\Program Files\\\\Microsoft VS Code\\\\bin\\\\code\" --wait
[pull]
	rebase = false
[credential]
	helper = manager
[credential "https://dev.azure.com"]
	useHttpPath = true
[init]
	defaultBranch = master
[safe]
	directory = *

[paulvxx]

Oddly enough, I was having the same Issue when I need to clone "googletest" as part of my make file build. (cmake ..)

Failed to clone 'third-party/google-test'. Retry scheduled
Cloning into '/home/user/openfhe-development/third-party/google-test'...
error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.

Attempting to install the submodule with

git submodule update --init --depth=1

seems to work (bypass the GnuTLS error), yet when I proceed onwards to actually building the program files, I now obtain a sort of error (see openfheorg/openfhe-development#409) which I would have not got if everything ran smoothly from the start (I verified this by attempting to set up the program files on a different machine)

$ make
Scanning dependencies of target third-party
-- Copied demoData files
[  0%] Built target third-party
Scanning dependencies of target coreobj
[  1%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/constants-lattice-impl.cpp.o
[  1%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/lattice.cpp.o
In file included from /home/user/openfhe-development-full/src/core/include/math/hal/bigintdyn/ubintdyn.h:51,
                 ...
/home/user/openfhe-development-full/src/core/include/utils/serializable.h:60:10: fatal error: cereal/cereal.hpp: No such file or directory
   60 | #include "cereal/cereal.hpp"
      |          ^~~~~~~~~~~~~~~~~~~

[See the Linux installation instructions of https://github.com/openfheorg/openfhe-development --- to attempt to replicate the exact issue]

[Balkoth]

git version 2.47.1.windows.1 now shows the following error:

Cloning into 'Repository'...
remote: Enumerating objects: 19199, done.
remote: Counting objects: 100% (19199/19199), done.
remote: Compressing objects: 100% (2193/2193), done.
error: RPC failed; curl 56 schannel: server closed abruptly (missing close_notify)
remote: Total 19199 (delta 18284), reused 17492 (delta 16998), pack-reused 0 (from 0)
Receiving objects: 100% (19199/19199), 6.83 MiB | 6.22 MiB/s, done.
Resolving deltas: 100% (18284/18284), done.
Updating files: 100% (2589/2589), done.

Having that version on both the server and the client.

[Balkoth]

Same with git version 2.47.1.windows.2

error: RPC failed; curl 56 schannel: server closed abruptly (missing close_notify)

[dscho]

Same with git version 2.47.1.windows.2

error: RPC failed; curl 56 schannel: server closed abruptly (missing close_notify)

This suggests to me that there is either a proxy or the server itself that enforce some sort of timeout, and that the sheer amount of data is the issue (which would be consistent with the report that shallow clones work: That reduces the amount of data to be transferred).

[Balkoth]

I don't think the Server itself hosting git-http-backend.exe is enforcing some timeout or else the complete clone would fail and not some command inside the clone chain.

As in my OP i already tried raising some limits that came up on a google search. If you have any input on what and where to configure then please advise.

Also let me know if you need more information on how to diagnose what is going on.

[dscho]

i already tried raising some limits that came up on a google search.

I suspect that there is nothing you can do locally, as it was the server that hung up unexpectedly, not the client.

I don't think the Server itself hosting git-http-backend.exe is enforcing some timeout or else the complete clone would fail and not some command inside the clone chain.

The command inside the clone chain that fails is on the local side. If it was Git itself that hung up, it would most likely send an error message first. To me, that indicates that it is the web server itself, or a proxy (such as a load-balancing proxy) that just cuts off the communication. In other words, my impression is that the problem is not at the application level, but at the transport level.

Also let me know if you need more information on how to diagnose what is going on.

Unfortunately I do not really have anything useful to say here. I would stab in the dark, just like you, for example trying to figure out whether this happens after the clone takes a specific number of seconds, or after a specific number of bytes was transferred. I would try to contact the administrator of the server and ask them to look in the server logs whether they can see anything unusual that would explain the symptoms.

[Balkoth]

The server administrator sent me this saying there is nothing in it that suggests the server itself is acting up:

#Software: Microsoft Internet Information Services 10.0
#Version: 1.0
#Date: 2025-01-24 08:48:28
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2025-01-24 08:48:28 SERVER_IP GET /path/to/Repository.git/info/refs service=git-upload-pack 443 - CLIENT_IP git/2.47.1.windows.2 - 401 2 5 123
2025-01-24 08:48:28 SERVER_IP HEAD / - 443 - CLIENT_IP Git-Credential-Manager/2.6.1.0+(Windows;+x86-64)+CLR/.NET+Framework+4.8.9282.0 - 401 2 64 8
2025-01-24 08:48:28 SERVER_IP GET /path/to/Repository.git/info/refs service=git-upload-pack 443 DOMAIN\user CLIENT_IP git/2.47.1.windows.2 - 200 0 0 56
2025-01-24 08:48:30 SERVER_IP POST /path/to/Repository.git/git-upload-pack - 443 DOMAIN\user CLIENT_IP git/2.47.1.windows.2 - 200 0 0 74
2025-01-24 08:48:34 SERVER_IP POST /path/to/Repository.git/git-upload-pack - 443 DOMAIN\user CLIENT_IP git/2.47.1.windows.2 - 200 0 0 4026