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

Re: Bad interaction between svn and OpenSSH auto connection pooling

From: Peter Samuelson <peter_at_p12n.org>
Date: 2007-03-03 23:52:14 CET

[Alan Barrett]
> Ideally, svn should close all the relevant file descriptors and wait
> for ssh to die by itself. If it doesn't die after a few seconds, kill
> it with SIGTERM; if it still doesn't die after a few more seconds, only
> then kill it with SIGKILL.

Setting a few-second timeout might not be trivial from within the
bowels of a library. It involves either blocking the whole thread, or
some sort of alarm and signal handling, with no knowledge of what the
host application might already be using these facilities for.

> svn currently kills it immediately with
> SIGKILL, which is very rude, and I call this a bug.

Yeah, http://subversion.tigris.org/issues/show_bug.cgi?id=2580 quotes
the comment that explains the SIGKILL: "Killing the tunnel agent with
SIGTERM leads to unsightly stderr output from ssh."

In Debianland, the ssh maintainers have patched out this "unsightly
stderr output", so I've changed svn's SIGKILL to the more conventional
SIGTERM+sleep+SIGKILL.

> On the ssh side, perhaps the control master should fork and
> daemonise itself, to insulate it from being killed by svn.

Well ... if you kill a process, doesn't that usually mean you really do
intend for it to die? I think ssh is already doing the right thing
there.

Peter

Received on Sat Mar 3 23:52:30 2007

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

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