Years ago, I attempted to fix an issue that sounds a lot like this:
https://hg.ucc.asn.au/dropbear/rev/35183e8a7851
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.
On Thu, Feb 25, 2021 at 12:52 PM Grant Edwards <grant.b.edwa...@gmail.com>
wrote:
> I have a small ash script that prints memory statistics once a second:
>
> #!/bin/sh
>
> 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 60
> done
>
> When I run that remotely via dropbea:
>
> $ ssh root@10.0.0.99 ./showmem.sh
>
> Everything works as expected while the ssh session is active, but when
> I end the ssh connection, the shell script never terminates: it
> continues to run (indifinitely, AFAICT). I don't recall this happening
> when we used to use openssh's server. Is there any way to get dropbear
> to terminate a "child" program when the ssh session closes?
>
>
>
>
>
