Volume XXII, number 280Wednesday, October 7, 2026Latest message 51 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

Re: 2.54.0: fyi: endless loop at 100% CPU

4 messages between Jun 27, 2026 and Jun 28, 2026, from Michael Montalbo, Steffen Nurpmeso.

Plain Markdown or JSON for tools and agents.

Michael MontalboJun 27, 2026, 19:39 UTC on lore
Steffen Nurpmeso <steffen@sdaoden.eu> writes:
Show 5 quoted lines
> I have no idea and i am not looking either, but my scripted update
> of tracked repos stuck, and i can a hundred percent reproduce an
> endless loop that consumes hundred percent CPU by doing
>
>  git ls-remote https://gitlab.xiph.org/xiph/opus.git
Hello, thank you for the report.

When I tried reproducing this locally I was able to get a response eventually, though there was what seemed to be a stall mid-way through the response from the server. After looking closer, the linked repo appears to be behind Anubis[1] which may be rate-limiting and/or blocking the requests from your script. FWIW, running:

GIT_TRACE_CURL=1 git ls-remote https://gitlab.xiph.org/xiph/opus.git 2>&1

locally showed the TLS handshake starting then pausing for a significant period of time before eventually completing the request successfully. Maybe running the command with the trace will show something on your end?

Also, here are some other potentially relevant configuration options [2][3]:
  git -c http.version=HTTP/1.1 \
  -c http.lowSpeedLimit=1000 \
  -c http.lowSpeedTime=10

[1] https://anubis.techaro.lol/ [2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpversion [3] https://git-scm.com/docs/git-config#Documentation/git-config.txt-httplowSpeedLimit

Steffen NurpmesoJun 27, 2026, 20:15 UTC in reply to Michael Montalbo on lore
Michael Montalbo wrote in
 <CAC2Qwm+48Gpj=AWHzx-nO00bwVfuYoGiwd=3gExbybcOyHC45Q@mail.gmail.com>:
 |Steffen Nurpmeso <steffen@sdaoden.eu> writes:
 |> I have no idea and i am not looking either, but my scripted update
 |> of tracked repos stuck, and i can a hundred percent reproduce an
 |> endless loop that consumes hundred percent CPU by doing
 |>
 |>  git ls-remote https://gitlab.xiph.org/xiph/opus.git
 |
 |Hello, thank you for the report.
 |
 |When I tried reproducing this locally I was able to get a response
 |eventually, though there was what seemed to be a stall mid-way
 |through the response from the server. After looking closer, the linked
 |repo appears to be behind Anubis[1] which may be rate-limiting
 |and/or blocking the requests from your script. FWIW, running:
 |
 |GIT_TRACE_CURL=1 git ls-remote https://gitlab.xiph.org/xiph/opus.git 2>&1

It now works for me. I cannot reproduce it no more. (Fwiw i got the same behavior for all repositories there, i track more from there.) (And no "network hang", that is, whatever, but it really busy looped!)

 |locally showed the TLS handshake starting then pausing for a significant
 |period of time before eventually completing the request successfully.
 |Maybe running the command with the trace will show something on your
 |end?
 |
 |Also, here are some other potentially relevant configuration options \
 |[2][3]:
 |  git -c http.version=HTTP/1.1 \
 |  -c http.lowSpeedLimit=1000 \
 |  -c http.lowSpeedTime=10
 |
 |[1] https://anubis.techaro.lol/
 |[2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-htt\
 |pversion
 |[3] https://git-scm.com/docs/git-config#Documentation/git-config.txt-htt\
 |plowSpeedLimit

Thanks for these pointers, i did not know about such configuration variables. I will set them like you show. Before i only had

  [http]
  sslVerify = true
  #sslCAInfo = /home/steffen/sec.arena/tls.git/cacert.pem
  sslTry = true
 --End of <CAC2Qwm+48Gpj=AWHzx-nO00bwVfuYoGiwd=3gExbybcOyHC45Q@mail.gmail\
 .com>
Thank you.  Ciao!
--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
Michael MontalboJun 27, 2026, 23:03 UTC in reply to Steffen Nurpmeso on lore
On Sat, Jun 27, 2026 at 1:16 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>
> Thanks for these pointers, i did not know about such configuration
> variables.  I will set them like you show.

No problem! Just to clarify, I'm not sure you should actually use those configuration values verbatim. I was more pointing in the direction of potentially relevant options for debugging / working around the issue.

Steffen NurpmesoJun 28, 2026, 16:37 UTC in reply to Michael Montalbo on lore
Michael Montalbo wrote in
 <CAC2Qwm+v2pRp30TYJpy8Wxzb7gbX+nzybZ_3A99cHb-xjjpCnQ@mail.gmail.com>:
 |On Sat, Jun 27, 2026 at 1:16 PM Steffen Nurpmeso <steffen@sdaoden.eu> \
 |wrote:
 |>
 |> Thanks for these pointers, i did not know about such configuration
 |> variables.  I will set them like you show.
 |
 |No problem! Just to clarify, I'm not sure you should actually use those
 |configuration values verbatim. I was more pointing in the direction of
 |potentially relevant options for debugging / working around the issue.

We'll see. But if there was some kind of "with love from canada" misconfiguration -- i have seen quite a bit of those, and permanent sub-second page reload was one of those effects, in a browser though .. and git has a little road 'till it gets to that stage (i hope) -- then maybe these settings .. Or i have to tweak.

Restartable "fetch" is likely not on that roadmap of git -- that would (have) be(en) so cool. (But for years i now have a WireGuard VPN and go through that, which has improved my TCP connectivity / stability massively. But it is still a thriller to go for some rate-limited fetch of large size ..)

Oh.  Maybe i see.
  $ git ls-remote https://gitlab.xiph.org/xiph/opus.git
  fatal: unable to access 'https://gitlab.xiph.org/xiph/opus.git/': Operation too slow. Less than 1000 bytes/sec transferred the last 10 seconds
  $ git ls-remote https://gitlab.xiph.org/xiph/opus.git
  fatal: unable to access 'https://gitlab.xiph.org/xiph/opus.git/': Operation too slow. Less than 500 bytes/sec transferred the last 10 seconds
  $ git ls-remote https://gitlab.xiph.org/xiph/opus.git
  fatal: unable to access 'https://gitlab.xiph.org/xiph/opus.git/': Operation too slow. Less than 500 bytes/sec transferred the last 21 seconds
It succeeds with
  lowSpeedLimit = 500
  lowSpeedTime = 33
But at least it does not busy loop:
  steffen   2960  2959   0  0.0   2738   2016 S+   00:00:00 18:26 pts/4    /usr/lib/git-core/git remote-https https://gitlab.xiph.org/xiph/opus.git https://gitlab.xiph.org/xiph/opus.git
  steffen   2961  2960   0  0.0  41213  11316 S+   00:00:00 18:26 pts/4    /usr/lib/git-core/git-remote-https https://gitlab.xiph.org/xiph/opus.git https://gitlab.xiph.org/xiph/opus.git

Unfortunately no info where and why it busy looped. If it would be non-blocking I/O and .. in this area, one could understand a bit. Some ticks-per-sec limit (without X progress) is not configurable? I am not really keen to create a rlimit wrapper for git, or whatever. (I have limiting cgroups, but still.)

A nice Sunday, Ciao and greetings from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Back to recent threads