On 2021-02-25, Catalin Patulea <c...@vv.carleton.ca> wrote:
> I believe the right way this works it that:
> - ssh client closes session
> - dropbear closes the read end of command's stdout pipe
> - next time command writes to pipe, it receives SIGPIPE and dies
> Thus I don't think dropbear needs to explicitly kill anything. but perhaps
> the mechanism is somehow not working.
>
> I would investigate this by running 'strace' on the remote host and seeing
> if, after closing the session, 1) dropbear closes the pipe and 2) the
> command tries to write to it and receives SIGPIPE.
Thanks for the clue!
The problem is that the executable I ran (ash) doesn't receive
SIGPIPE. What receives the SIGPIPE are the `date` utility and the
`sort` utilities. They die when they try to write to stdout, but the
shell program that invoked them continues to run.
The same thing happens with the openssh server.
In this case I can fix it by setting the `errexit` shell option in the
shellscript I'm running so that the shell will exit when `date` or
`sort` exit with an error. [This would not work if `sort` and `date`
exited with status 0 when receiving SIGPIPE.]
#!/bin/sh
set -o errexit
while true
do
date
cat /proc/[0-9]*/stat |
awk '$23 > 0 {printf "%5d %20s %8d %5d\n", $1, $2, $23, $24}' |
sort -n
sleep 15
done
Another work-aroud is to force allocation of a tty like this:
$ ssh -t root@10.0.0.99 ./showmem.sh
That way when the user presses ctrl-C and ssh client gets a SIGINT,
the SIGINT will also be sent to the members of the tty group at the
server end. However, if the user exits the ssh client by typing "~."
instead of hitting ctrl-C, the program will continue to run as before
