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