# Re: 2.54.0: fyi: endless loop at 100% CPU 4 messages from 2026-06-27 to 2026-06-28. Participants: Michael Montalbo, Steffen Nurpmeso. Thread: https://gitlist.dev/t/65881 ## Michael Montalbo, 2026-06-27 19:39 Subject: Re: 2.54.0: fyi: endless loop at 100% CPU Message-ID: ``` Steffen Nurpmeso 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 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 Nurpmeso, 2026-06-27 20:15 Subject: Re: 2.54.0: fyi: endless loop at 100% CPU Message-ID: <20260627201558.Bw6A-jbx@steffen%sdaoden.eu> In-Reply-To: ``` Michael Montalbo wrote in : |Steffen Nurpmeso 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 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 Montalbo, 2026-06-27 23:03 Subject: Re: 2.54.0: fyi: endless loop at 100% CPU Message-ID: In-Reply-To: <20260627201558.Bw6A-jbx@steffen%sdaoden.eu> ``` On Sat, Jun 27, 2026 at 1:16 PM Steffen Nurpmeso 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 Nurpmeso, 2026-06-28 16:37 Subject: Re: 2.54.0: fyi: endless loop at 100% CPU Message-ID: <20260628163748.ewryhWxh@steffen%sdaoden.eu> In-Reply-To: ``` Michael Montalbo wrote in : |On Sat, Jun 27, 2026 at 1:16 PM Steffen Nurpmeso \ |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) ```