I've been puzzling over the disparate exit codes returned by ssh when the remote command is killed by a signal: $ ssh host1 'kill -HUP $$'; echo $? 129 $ ssh host2 'kill -HUP $$'; echo $? 255 This results from the interaction of (a) the behavior of the login shell and (b) an implementation gap in OpenSSH's ssh(1) client. If the login shell is bash, its exit triggers the WIFSIGNALED() check in session_exit_message() and an "exit-signal" message is sent. However, client_input_channel_req() does not handle "exit-signal" at all, exit_status is not set and retains its initial value -1. Therefore ssh returns 255. If the login shell is OpenBSD's ksh, its exit triggers the WIFEXITED() check instead and an "exit-status" message is sent. This is handled in client_input_channel_req, and ssh returns the received exit code of 128 + signal. This is not the place to discuss the correctness of the respective shell behavior. However, shouldn't ssh(1) handle "exit-signal" and synthesize an exit status of 128 + signal? -- Christian "naddy" Weisgerber naddy@xxxxxxxxxxxx _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
