Request: timeout option for remote operations, esp. "git fetch"
When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout.
-hpa
Quoted 3 lines · H. Peter Anvin
When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout.
We've had SO_KEEPALIVE on git and ssh transports since e47a8583 (2011-12-06) SO_KEEPALIVE for http was added recently (a15d069a) and will be in git 1.8.5
Do you want a shorter timeout for slow (but still alive) servers?
Quoted 10 lines · Eric Wong
Quoted 3 lines · H. Peter Anvin
When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout.
We've had
SO_KEEPALIVEon git and ssh transports sincee47a8583(2011-12-06)SO_KEEPALIVEfor http was added recently (a15d069a) and will be in git 1.8.5Do you want a shorter timeout for slow (but still alive) servers?
Yes; note that SO_KEEPALIVE only guarantees that the server is alive at the TCP socket level. If the server is overloaded but technically alive it may still make no meaningful forward progress.
-hpa
Quoted 9 lines · H. Peter Anvin
Quoted 8 lines · Eric Wong
Quoted 3 lines · H. Peter Anvin
When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout.
We've had
SO_KEEPALIVEon git and ssh transports sincee47a8583(2011-12-06)SO_KEEPALIVEfor http was added recently (a15d069a) and will be in git 1.8.5
Quoted 6 lines
Quoted 2 lines
Do you want a shorter timeout for slow (but still alive) servers?
Yes; note that
SO_KEEPALIVEonly guarantees that the server is alive at the TCP socket level. If the server is overloaded but technically alive it may still make no meaningful forward progress.
Which means that your original wish may not be granted with SO_KEEPALIVE at all, no? I was wondering if you wanted a forced timeout based on alarm(2), something similar to what you added to git-daemon in 960deccb (git-daemon: timeout, eliminate double DWIM, 2005-10-19).
Quoted 18 lines · Junio C Hamano
Quoted 9 lines · H. Peter Anvin
Quoted 8 lines · Eric Wong
Quoted 3 lines · H. Peter Anvin
When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout.
We've had
SO_KEEPALIVEon git and ssh transports sincee47a8583(2011-12-06)SO_KEEPALIVEfor http was added recently (a15d069a) and will be in git 1.8.5Quoted 6 lines
Quoted 2 lines
Do you want a shorter timeout for slow (but still alive) servers?
Yes; note that
SO_KEEPALIVEonly guarantees that the server is alive at the TCP socket level. If the server is overloaded but technically alive it may still make no meaningful forward progress.
Quoted 6 lines
Which means that your original wish may not be granted with
SO_KEEPALIVEat all, no? I was wondering if you wanted a forced timeout based on alarm(2), something similar to what you added to git-daemon in960deccb(git-daemon: timeout, eliminate double DWIM, 2005-10-19).
Yes, something more like that on the client end. SO_KEEPALIVE is better than nothing, but not really good enough.
-hpa
Quoted 9 lines · H. Peter Anvin
Quoted 6 lines
Which means that your original wish may not be granted with
SO_KEEPALIVEat all, no? I was wondering if you wanted a forced timeout based on alarm(2), something similar to what you added to git-daemon in960deccb(git-daemon: timeout, eliminate double DWIM, 2005-10-19).Yes, something more like that on the client end.
SO_KEEPALIVEis better than nothing, but not really good enough.
Would it be enough to just use timeout(1), like:
timeout 10m git fetch
That will time the _whole_ fetch operation, which means a legitimately gigantic but fast fetch would still fail. Setting a shorter timeout only for periods of inactivity on the network socket would catch killed or very laggy connections. But it would not catch a server that feeds you data at a constant but ridiculously slow rate.
-Peff