Long running hooks result in broken pipe


I have a hook which needs some minutes to finish.

I get this error during a git client push to Gogs:

2019/10/23 19:34:08 [ERROR] [.../routes/repo/http.go:261 serviceRPC()] HTTP.serviceRPC: fail to serve RPC 'receive-pack': signal: broken pipe -

The client output this:

error: RPC failed; HTTP 404 curl 22 The requested URL returned error: 404 Not Found
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

The hooks maximum possible runtime in my installation is around 50 seconds. I think there is some overall timeout of 60 seconds.

  • Is there any setting to increase this timeout?

Then I discovered that the remote-output of the hooks is not sent to client before the hook has finished. So somewhere the complete output is stored in memory. I think this should be streamed.

  • But I don’t know if this is caused by git API or could be changed by Gogs?!

Should I do a bug report?

I have found my responsible timeout…

It is the Apache ReverseProxy.
I could configure the timeout with a parameter at the ProxyPass

Do you know about the handling of the remote-output?

The relevant code path is here:

It seems no timeout on Gogs side, and stream output for stdout, but stderr is cached until finished.

What type of hook is it? There could be some Git commands ran by hook that has 60s timeout.

Oh, I just saw your second post after my reply… good to know!

But yes, What type of hook is it?

It is self-scripted… a poor man’s CI/CD.
Special tag-refs execute build and deployment.
So it is ok to run a few minutes, this is intended.

I made a webhook that could take some minutes to finish, and received those errors too, in the end I used celery in the backend to run those scripts.

1 Like

Sorry, I wasn’t clear, which Git hook did you hook? Is it pre-receive, update or post-receive?

Ah. In post-receive.

Thanks. Don’t have heard about celery.
But I like to see the success or fail of the hook on git push.
No idea how I should get the status of a decoupled solution in git.

I think the code directly write output to a stream, could be cause by the nature of HTTP request/response. Maybe you wanna try push via SSH.

After the solution for the timeout, I could see that the output is received in bigger blocks (a few kbytes). So there seems to be some buffering. But I can live with this now.