git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Bug report: Git pull hang occasionally

From
KZKai Zhang <kai@netskope.com>
Date
Dec 21, 2016, 21:10 UTC
Message-ID
<EB5CD780-BDDA-44C5-BD7D-1325F5891926@netskope.com>
In-Reply-To
<xmqq8tr9huc0.fsf@gitster.mtv.corp.google.com>
Thank you for your insight and detailed explanation Junio.
I think what you said is what is happening in my environment. Both writing and reading are happening simultaneously. 
Show 40 quoted lines
> On Dec 21, 2016, at 12:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Kai Zhang <kai@netskope.com> writes:
> 
>> 2016/12/20 20:38:10 [error] 9957#0: *687703 FastCGI sent in stderr: "fatal: 'HEAD' is a symref but it is not?" while reading response header from upstream, client: 10.1.0.11, server: server, request: "POST /git/repo_name/.git/git-upload-pack HTTP/1.1", upstream: "fastcgi://unix:/var/run/fcgiwrap.socket:", host: "server"
> 
> (Not a solution)
> 
> In order to tell the client if HEAD is a symbolic ref and to what
> underlying ref it points at if it is a symbolic ref, at the very
> beginning of upload-pack, there is a call to head_ref_namespaced()
> that uses find_symref().  find_symref() gets "HEAD" and a boolean
> that says if it is a symbolic ref, but it does not get where the
> symbolic ref points at, so it does resolve_ref_unsafe() to learn
> that information.
> 
> Between the time head_ref_namespaced() checks the refs database and
> finds that HEAD is a symbolic ref, and the time find_symref() calls
> resolve_ref_unsafe() to find out where it leads to, if somebody else
> updates HEAD, resolve_ref_unsafe() can give an unexpected result, as
> all of these read-only operations are performed without any locking.
> 
> And the unexpected discrepancy is reported by find_symref() as
> fatal.  The server side dies, and somehow that fact is lost between
> the upload-pack process and the client and somebody in the middle
> (e.g. fastcgi interface or nginx webserver on the server side, or
> the remote-curl helper on the client side) keeps the "git fetch"
> process waiting.
> 
> So there seem to be two issues.  
> 
> - Because of the unlocked read, find_symref() can observe an
>   inconsistent state.  Perhaps it should be updated not to die but
>   to retry, expecting that transient inconsistency will go away.
> 
> - A fatal error in upload-pack is not reported back to the client
>   to cause it exit is an obvious one, and even if we find a way to
>   make this fatal error in find_symref() not to trigger, fatal
>   errors in other places in the code can trigger the same symptom.
> 
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 8 in “Bug report: Git pull hang occasionally”
  1. Kai ZhangDec 21, 2016
  2. Junio C HamanoDec 21, 2016
  3. Kai ZhangDec 21, 2016
  4. Junio C HamanoDec 21, 2016
  5. Kai ZhangDec 21, 2016
  6. Kai ZhangJan 12, 2017
  7. Junio C HamanoJan 12, 2017
  8. Kai ZhangJan 12, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.