[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

xinetd and TCP keepalive

From: Vincent Caron <vcaron_at_bearstech.com>
Date: Tue, 19 May 2009 16:58:11 +0200

Hello,

   I'm posting this mail (as a non-member of this list), as required by
the "Buddy system" for bug filing.

   This is a simple but important configuration issue with
xinetd+svnserve that hit me with Subversion 1.5.1 (as packaged in Debian
5.0 Lenny, arch is amd64).

   I have a production server whith SVN repositories reached via SSH and
svnserve. The frontend is 'xinetd' for the latter. Recently I realized
there were sleeping 'svnserve' processes as old as 6 months. Using
'strace' it showed that it was blocked while reading on stdin (names and
IP changed):

serv:~# strace -p 8411
Process 8411 attached - interrupt to quit
read(0, <unfinished ...>
Process 8411 detached

serv:~# ll /proc/8411/fd/
total 3
lrwx------ 1 root root 64 May 19 11:23 0 -> socket:[75724736]
lrwx------ 1 root root 64 May 19 11:23 1 -> socket:[75724736]
lrwx------ 1 root root 64 May 19 11:23 2 -> socket:[75724736]

serv:~# netstat -ane|grep 75724736
tcp 0 0 1.2.3.4:svn 5.6.7.8:42833 ESTABLISHED root 75724736

   On the other end (not a client but a NAT router), there were no trace
of this venerable 6-month old TCP session. Then 'man 7 tcp' enlightened
me: "Keep-alives are only sent when the SO_KEEPALIVE socket option is
enabled".

   'svnserve' in inetd mode could block indefinitely on a read() (it's
not supposed to know it's a socket so it's right IMHO), and no TCP
traffic means no chance to reset the session.

   I've simply added the "flag = KEEPALIVE" parameter in my xinetd.conf
service description. I've not found any references to this flag on blogs
and documentation, and it looks like it's fixing my bug. Then the
default for this xinetd option might differ between distros (it's
globally off as default on Debian). But it should be safer to add this
parameter.

   Addendum: those blocked svnserve are connected to legitimate,
authenticated-only clients. No real worries about attacks or such.

   I'm not sure if it's really a svnserve bug or feature, so I simply
propose to document a complete xinetd subversion service block (see
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html):

service svn
{
   socket_type = stream
   flags = KEEPALIVE
   protocol = tcp
   port = 3690
   wait = no
   user = svn
   group = rsvn
   server = /usr/bin/svnserve
   server_args = -i -r /var/lib/svn
   disable = no
}

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2313431

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-19 17:05:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.