Bash script dd and fsck not killed

Question

I need to remove a lv which is under use from a script which is doing a dd, fcsk and some more tasks on some peer node.so am just killing the script and trying to remove the lv from that peer, but it seems not working with error open lvs.

but for the same case if i kill the dd then removing the lv its working fine. may be am asking a silly question but need to know why so??

Answer 1

If you kill your script sending SIGTERM or SIGKILL to its PID, normally you would send the signal only to the parent process. dd is running in a child process which won't receive the signal. Once the parent is killed, the child is inherited by init and it will keep on running.

To send the signal to the whole process group use:

kill -- -PID

or

kill -9 -PID

where PID is the PID of your script. Note the minus sign prepended to PID. From man kill

-n     where n is larger than 1.  All processes in process group n are signaled.

Example

I am running dd from a shell script:

 PID  TGID   TID  PGID  PPID COMMAND
 5828  5828  5828  5828 20127 sh
 5829  5829  5829  5828  5828 dd

The Process Group ID (PGID) is the PID of the parent (5828).

If I run the following command:

kill -9 5828

I obtain the following situation:

 PID  TGID   TID  PGID  PPID COMMAND
 5829  5829  5829  5828     1 dd

dd is still running and it has been inherited by init (PPID is 1). If instead I run:

kill -9 -5828

both the script and dd are killed.

EDIT: The process you want to kill is launched remotely via ssh.

Having ssh launch dd/fsck remotely changes everything. A simple but not recommended solution could be the following.

A script launches dd/fsck remotely via ssh in the background and gets the PID.

remote_pid=$(ssh user@host 'dd if=/dev/urandom of=/dev/zero & echo $!')

Then the script must not return and trap your signal. Your handler opens a new ssh connection and signals remote_pid.

Cleaning up in a second ssh connection is not recommended, as it could fail and leave a lot of mess behind.

For a more advanced solution please see https://unix.stackexchange.com/questions/40023/get-ssh-to-forward-signals