> 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
> 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
Received on Sat Mar 3 23:52:30 2007