# Request: timeout option for remote operations, esp. "git fetch" 6 messages from 2013-11-07 to 2013-11-14. Participants: H. Peter Anvin, Eric Wong, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/35295 ## H. Peter Anvin, 2013-11-07 17:07 Subject: Request: timeout option for remote operations, esp. "git fetch" Message-ID: <527BC8DC.7010108@zytor.com> URL: https://gitlist.dev/e/527BC8DC.7010108%40zytor.com ``` 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 ``` ## Eric Wong, 2013-11-10 20:17 Subject: Re: Request: timeout option for remote operations, esp. "git fetch" Message-ID: <20131110201751.GA18513@dcvr.yhbt.net> URL: https://gitlist.dev/e/20131110201751.GA18513%40dcvr.yhbt.net In-Reply-To: <527BC8DC.7010108@zytor.com> ``` "H. Peter Anvin" wrote: > 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? ``` ## H. Peter Anvin, 2013-11-12 17:00 Subject: Re: Request: timeout option for remote operations, esp. "git fetch" Message-ID: <52825EBF.3050603@zytor.com> URL: https://gitlist.dev/e/52825EBF.3050603%40zytor.com In-Reply-To: <20131110201751.GA18513@dcvr.yhbt.net> ``` On 11/10/2013 12:17 PM, Eric Wong wrote: > "H. Peter Anvin" wrote: >> 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? > 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 ``` ## Junio C Hamano, 2013-11-12 17:45 Subject: Re: Request: timeout option for remote operations, esp. "git fetch" Message-ID: URL: https://gitlist.dev/e/xmqq1u2likea.fsf%40gitster.dls.corp.google.com In-Reply-To: <52825EBF.3050603@zytor.com> ``` "H. Peter Anvin" writes: > On 11/10/2013 12:17 PM, Eric Wong wrote: >> "H. Peter Anvin" wrote: >>> 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? >> > > 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. 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). ``` ## H. Peter Anvin, 2013-11-12 18:33 Subject: Re: Request: timeout option for remote operations, esp. "git fetch" Message-ID: <5282748D.9000907@zytor.com> URL: https://gitlist.dev/e/5282748D.9000907%40zytor.com In-Reply-To: ``` On 11/12/2013 09:45 AM, Junio C Hamano wrote: > "H. Peter Anvin" writes: > >> On 11/10/2013 12:17 PM, Eric Wong wrote: >>> "H. Peter Anvin" wrote: >>>> 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? >>> >> >> 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. > > 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). > Yes, something more like that on the client end. SO_KEEPALIVE is better than nothing, but not really good enough. -hpa ``` ## Jeff King, 2013-11-14 08:01 Subject: Re: Request: timeout option for remote operations, esp. "git fetch" Message-ID: <20131114080122.GA16327@sigill.intra.peff.net> URL: https://gitlist.dev/e/20131114080122.GA16327%40sigill.intra.peff.net In-Reply-To: <5282748D.9000907@zytor.com> ``` On Tue, Nov 12, 2013 at 10:33:49AM -0800, H. Peter Anvin wrote: > > 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). > > > > Yes, something more like that on the client end. SO_KEEPALIVE is 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 ```