2

I am running a script which has to be suspended before killing. 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. First of all why this behaviour? And how can I kill all the suspended processes without explicitly mentioning each PID?

./toplog.sh

Suspending:

Ctrl-Z

Listing suspended processes:

jobs -l

Output:

[1]  12055 Stopped                 ./toplog.sh
[2]  12752 Stopped                 ./toplog.sh
[3]- 13276 Stopped                 ./toplog.sh
[4]+ 13579 Stopped                 ./toplog.sh

Killing:

kill 12055 12752 13276 13579
2
  • 2
    With bash: kill %{1..4}. – Satō Katsura Oct 22 '16 at 9:45
  • @SatoKatsura What would be the reason behind increasing number of PID in subsequent calls? – Sudip Bhandari Oct 22 '16 at 9:53
4

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.

0

You can kill all instances of your script when you know how your process is called during runtime (in this example toplog.sh).

ps x | grep toplog.sh | grep -v grep | cut -d" " -f1 | xargs kill -9

ps x is giving you a list of all your processes where from the target process will be grepped. The second grep just makes sure to remove the grep call itself from the list. Otherwise you get an error (which in fact is still no problem but it's ugly). cut -d" " -f1 cuts every line into multiple parts divided by space characters whereby *-f1** takes the first part. xargs kill -9 kills every pid that is thrown out of the command chain before.

For convenience you can put this line into a kill script whereby the process name is substituted with the kill script argument:

#!/bin/bash
ps x | grep $1 | grep -v grep | cut -d" " -f1 | xargs kill -9

The script is then called with the name of the to be killed processes.

./kill.sh toplog.sh

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.