Remote program doesn't terminate when ssh session ends

[Grant Edwards]

On 2021-02-25, Catalin Patulea <cat at 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 at 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