I am running a script which has to be suspended before killing.
Uh, no. A script doesn't need to be suspended before killing. You can kill it at any time.
The first time I run it there is only one pid for the process. I kill it and run again and the number of PID goes increasing.
Then you aren't actually killing it! If you run ./toplog.sh
and suspend it, that only creates a single job, i.e. a single line in the output of jobs
. The script itself might create multiple processes, but jobs
only lists the script itself (the process group leader, in technical terms). If you see more and more jobs, that means that you're still seeing the old jobs that you unsuccessfully tried to kill.
The reason you failed to kill the jobs is probably because they're suspended. When a process is suspended, it can't react to signals. If you send a signal to a suspended process, the signal only has an effect when the process is resumed. The exceptions are signals which are managed by the kernel directly, without involving the process. One such exception is the signal to resume a process (SIGCONT) obviously does wake up the process immediately. Another category of exceptions is signals that kill the process without asking: this always includes SIGKILL, and also includes other signals (SIGINT, SIGHUP, SIGTERM, SIGQUIT, …) if the process hasn't set a handler for that signal.
If kill %1
kills job 1, then the shell will tell you that the job is terminated. If the process has set a handler for SIGTERM, then kill %1
has no effect while the process is suspended; to kill the process, you also need to resume it:
kill %1; kill -CONT %1
If you want to force-kill the process without giving it any opportunity for cleanup, then do
kill -KILL %1
(or kill -9 %1
for short).
If you want to kill all the toplog.sh
processes, whether they were launched from this terminal or not, you can use pkill toplog.sh
.
bash
:kill %{1..4}
.