Re: [Savannah-users] Savannah reboots today

[Eric Wong]

Bob Proulx <address@hidden> wrote:
<snip> Thanks for the writeup!

> Eric Wong wrote:
> > By default, SO_KEEPALIVE still takes around 2 hours to detect a
> > failed connection, so it's probably worth tweaking the
> > /proc/sys/net/ipv4/tcp_keepalive_* knobs, too.
> 
> Yes.  The defaults are very long.  Starting the tweaks I started with
> these values.
> 
>   net.ipv4.tcp_keepalive_time = 600
>   net.ipv4.tcp_keepalive_intvl = 60
>   net.ipv4.tcp_keepalive_probes = 3
> 
> I may have made these too short for some networks.  Comments?

The tcp_keepalive_time could probably be made shorter but use
more probes; but, I'm not sure, either...

Prematurely aborting a slow connection is painful since git does
not yet support resuming (hopefully it can be implemented this
year).

Btw, I'm wondering if you can share any data on slow connections
project sizes so git developers can work to improve things.

> > I use xinetd myself for git-daemon, and have always had
> > SO_KEEPALIVE enabled in my /etc/xinet.d/git via:
> >
> >     flags           = KEEPALIVE
> 
> Ah...  I was unaware of that!  We have not had that enabled there.
> Thank you for this hint.  I think that is a very worthy addition.  I
> will enable it in our flags too and credit you for the suggestion.

No problem!  We might also update the git docs for folks who
read new docs on the web but could be running an old git.

> > But I guess git-daemon should be doing setsockopt to enable
> > SO_KEEPALIVE itself...  I'll test + post patches to the git
> > mailing list soonish.  I added SO_KEEPALIVE to the client-side
> > of git years ago, but forgot the daemon :x.

git 1.8.4.2 and later sends keepalive packets every 5s while
generating the pack; so maybe SO_KEEPALIVE is not such a big
help nowadays.  SO_KEEPALIVE should still help during init when
--init-timeout is not set, though.

> > I forgot git-daemon has --timeout/--init-timeout options which I guess
> > weren't used?  Yikes :x
> 
> It looks like they are not used.  There is a global wrapper using
> the command line 'timeout' however.  It reaps too long running
> processes.  Note that timeouts must accomodate clients on slow
> connections pulling large projects.

Relying on built-in timeouts in git (even high timeouts) should be
better for large projects and slow connections, even.  git knows
when it's making any progress to not drop a slow connection;
'timeout' would not.

'timeout' might still be useful if you have slow clients
intentionally DoS-ing you by trickling requests and nibbling
responses, though.