I'll go one farther than the submitter of #313371 and claim that *all*
the "Killed by signal N" messages are unneeded. Most Unix programs
don't print such messages; that's the shell's job.
The reason I care is that subversion can use a ssh pipe, and needs to
be able to kill the pipeline when it is done. The comment in the
subversion source is illuminating:
/* Arrange for the tunnel agent to get a SIGKILL on pool
* cleanup. This is a little extreme, but the alternatives
* weren't working out:
...
* - Killing the tunnel agent with SIGTERM leads to unsightly
* stderr output from ssh.
*/
SIGKILL is, as the comment notes, "a little extreme". For one thing,
if "ControlMaster auto" is in effect, ssh can't remove its socket file.
In my opinion, at least SIGTERM and SIGINT should not print a warning
to stderr. SIGTERM is long-accepted way to kill something "just
because it's time for it to die now", and SIGINT is usually a keyboard
command, so in both cases the user should already know why subversion
is dying. If she wants to hear more about it, she'll be running a
shell that will tell her about signal exit statuses.
It's more useful to warn on death-by-SIGFPE or death-by-SIGABRT or some
of those others, but I'd still argue that it isn't *necessary*.
--- clientloop.c~
+++ clientloop.c
@@ -1505,8 +1505,16 @@
exit_status = 0;
}
- if (received_signal)
- fatal("Killed by signal %d.", (int) received_signal);
+ /*
+ * SIGTERM and SIGINT are usually done on purpose by the user; no
+ * need to be noisy about getting them. The extra noise is, for
+ * one thing, annoying when ssh is run and killed noninteractively.
+ */
+ if (received_signal) {
+ if (received_signal != SIGTERM && received_signal != SIGINT)
+ fatal("Killed by signal %d.", (int) received_signal);
+ cleanup_exit(received_signal + 128);
+ }
/*
* In interactive mode (with pseudo tty) display a message indicating
Attachment:
signature.asc
Description: Digital signature