What state are the processes in when they can't be killed? "State D" processes generally have to come out of state D (when their I/O finishes) before they look at their signals and state Z processes can't be killed no matter what (short of the parent reaping the child or the admin rebooting the machine). My thinking is that using another command might be just you doing something else for a while and the processes change state on you.
–
BratchleyMay 6 '13 at 15:07

2

Does pgrep "run_tcp_sender.sh" return the list of processes you want to kill, or does it just return an empty list because the processes are all listed as bash run_tcp_sender.sh ...?
–
Jonathan CallenMay 6 '13 at 17:22

Defines the signal to send to each matched process. Either the
numeric or the symbolic signal name can be used. (pkill only.)

Issues with pkill

The OP mentioned that he was unsuccessful in getting pkill -SIGKILL "run_tcp" to work. We initially thought that the issue had to do with pkill potentially killing itself before it had finished killing all the "run_tcp" processes.

But that was hard to accept given a foot note in the pkill man page:

The running pgrep or pkill process will never report itself as a match.

In addition to that, @Gilles left a comment basically saying the same thing, that pkill just does not kill itself. Then he gave us a pretty big clue as to what was actually going on.

Here's an example that demonstrates what the OP and myself were missing:

Doing the ps command from above, we see that none of the processes were killed, just like the OPs issue. What's going on?

Turns out this is an issue in how we were attempting to make use of pkill. The command:

pkill -SIGTERM "sleepy.bash"

was looking for a process by the name of "sleepy.bash". Well there aren't any processes by that name. There's processes that are named "bash sleepy.bash" though. So pkill was looking for processes to kill and not finding any and then exiting.

References

Not sure, that signals the application to shut itself down, but it isn't responding. The SIGKILL, is the OS destroying the process, which is a little heavy handed to use all the time. Better to let the application close itself if it can.
–
slm♦May 6 '13 at 14:32

This is unrelated to the parent process ID. The problem is simply that you are killing all the processes running run_tcp_sender.sh, but you have no such processes — the processes you're interested in are running bash.

You can instruct pkill to match on the whole command line:

pkill -f '^bash run_tcp_sender.sh'

Another approach would be to kill all the processes that have the script open. That could make collateral damage, e.g. to an editor that was just opening the script.

fuser -k /path/to/run_tcp_sender.sh

As long as you aren't editing the script as root, killing only root's processes would solve that issue: