OS X (Apple)

I'm in a situation where I am executing a shell script(Bash) on another machine remotely using ssh, and for various reasons sometimes need to quit it and restart it. The shell script being run does many different things, so its hard to know what process to kill on the remote machine, and even if I do it will just skip to the next line of the shell script.

At the moment my solution is to just have the remote machine Kill the Terminal. This is a very unsexy solution to me because the remote machine may need to have the terminal open for other reasons and this will end those other processes.

One thing that could be relevant is that I know the name of the terminal window my shell script is being run in. So if I could somehow just kill that specific window and leave the rest open, that would work perfectly.

Any help is much appreciated! -Cheers DD

Very strange design. Do you mean to say that the remote script creates concurrent processes all of which block signals? Some signals cannot be blocked. And once a parent process dies the children are then "inherited" by the init process.

The term you want is session leader or session owner. That is the process which owns the terminal.

Sounds like that script should keep ownership of the children and then respond correctly to a SIGTERM signal - tell the children to die, reap them and exit. What you describe is a little on the pathological side, IMO.

One way to deal with it:
If you do not have pstree, install it with homebrew. pstree will show you the process tree your pathological script has created. This means you can kill off all of the Addams family with

Code:

ssh  me@remotebox 'kill -9 childpid1 childpid2 .... childpidn, parentpid'

BTW

Code:

kill -9

is a last resort, your code really should recognize more standard signals and respond correctly. This kill command does not let the processes shutdown correctly - it just obliterates them - go directly to jail, do not pass Go, do not collect $200.

To me that sounds like the requestor has a terminal session open permanently just to run that script, constantly. If that's the case, wouldn't this be an ideal candidate for a self-sufficient "daemon" script that you kick off - in the terminal, using cron, during boot - and then leave alone running happily, logging its progress to a (system?) file, so you can check what it does, or even mailing you should problems occur.