|Issue 5669:||git push failing with 'error: RPC failed; result=35, HTTP code = 0'|
|13 people starred this issue and may be notified of changes.||Back to list|
I wanted to have a Git mirror for the fiji-bi project, but on initial push, it fails: $ git push https://code.google.com/p/fiji-bi/ master Counting objects: 38777, done. Delta compression using up to 2 threads. Compressing objects: 100% (12306/12306), done. Writing objects: 100% (38777/38777), 155.66 MiB | 68.09 MiB/s, done. Total 38777 (delta 24216), reused 37336 (delta 23113) error: RPC failed; result=35, HTTP code = 0 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly With GIT_CURL_VERBOSE=1, the relevant part reads: Counting objects: 38777, done. Delta compression using up to 2 threads. Compressing objects: 100% (12306/12306), done. Writing objects: 100% (38777/38777), 155.66 MiB | 172.65 MiB/s, done. Total 38777 (delta 24216), reused 37336 (delta 23113) * About to connect() to code.google.com port 443 (#0) * Trying 184.108.40.206... * connected * Connected to code.google.com (220.127.116.11) port 443 (#0) * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none * SSL re-using session ID * error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message * Closing connection #0 error: RPC failed; result=35, HTTP code = 0 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly I am on Ubuntu and use the latest Git from Junio's 'next' branch, but it was the identical problem with a two-month old version from which I upgraded in the hope to fix this issue.
Aug 6, 2011
Oops, sorry, this should not have been labeled as enhancement...
Aug 6, 2011
Okay, more clues: it now also happens with a project where pushing worked previously: msysgit. Same setup, same client. The last successful push was on July 20th, after that, there was nothing to push yet until today :-)
Aug 6, 2011
Yet another clue: on another machine with libcurl4-openssl-dev 7.19.7-1ubuntu installed, the push works. The machine with the failure has 7.18.0-1ubuntu, which is pretty current and the state of the art on x86_64 Ubuntu 8.04.4 LTS. With a self-compiled curl 7.21.7, it works, but that situation is not ideal (what with a Long Term Support version of Ubuntu not working together nicely with Google Code).
Aug 6, 2011
(No comment was entered for this change.)
Labels: -Type-Enhancement Type-Defect Component-Git
Aug 10, 2011
I suspect the fact that you successfully pushed fiji-bi eventually means it's a transient error on our end with large packs (which we've seen before, unfortunately), rather than an issue with your git client. (I think the SSL error message is related to the stream terminating unexpectedly and not an actual SSL-related issue. At least I hope so, because we use the same SSL code as the rest of Google :) Unfortunately, I missed when you filed this bug, so I think we've expired some of the logs that would help me debug. Please let me know if you see anything like this again, especially if it continues to be repeatable for more than a few minutes.
Aug 10, 2011
Well, I tried with multiple clients and stopped when it looked as if it succeeded, went back to the old client and the problem was still there. So it was definitely not a transient issue, it was definitely a problem with the old cURL library (which I no longer have, but all those Ubuntu LTS users, quite a number if you ask me). Note also that the error happened before any real data were sent. So I don't think that the stream terminated because of a large pack. Besides, the exact same issue happened with a relatively small repository (<10MB). I will not experience something like this again because I will not downgrade, but if you are serious about wanting to fix that bug, you should be able to reproduce easily by taking a plain Ubuntu 10.04 LTS, installing libcurl4-dev, cloning a current Git, building it, and just pushing Git's own repository to Google Code. Besides, that result code 35 probably tells you more than it tells me. Thanks for your attention.
Aug 10, 2011
Interesting, you've convinced me it's not what I thought. I don't have any Hardy machines available but I can certainly try those libcurl and git versions. The error codes don't mean much to me, frankly. The whole "RPC failed" thing is a crufty error message from the remote helper talking to the process using curl. But I'll pass this along to Shawn and Jun and see if it rings any bells with them. Could you do me a favor and try one more small push with a version you think will fail? We just cut a new release today and I'd like to see some logs from that.
Aug 11, 2011
I reverted the curl version on our production machine to the very same state I told you about, possibly upsetting a few users and cronjobs. It still fails in exactly the same manner as I described, and since I have not a chance to know what your new release did (or for that matter, what the internals are and what might solve the issue), it might not be the best idea to continue with you changing something, suggesting to test, me in another time zone reverting to an earlier version on a production system and reporting that it still fails. I sincerely think that it should have something to do with the ssl negotiation, quite possibly with the way cURL used to use OpenSSL previously, since in the succeeding setup with GIT_CURL_VERBOSE=1, I see: * SSL re-using session ID * SSL connection using RC4-SHA So somewhere between those two debug messages, things go wrong, with only one component exchanged: cURL. Neither Git nor OpenSSL were replaced to fix the issue.
Jul 31, 2012
I have similar error messages but HTTP code is different. My observation is that http git server can't handle batch push very well. So instead, I use script like following to push one file at a time. sleep command is not really necessary. for i in *.gz; do git add $i;git commit $i -m "add $i";git push -v; sleep 5; done hope this work around works for you.
|► Sign in to add a comment|