Re: Problem using dd within bash script

[Pádraig Brady]

On 04/25/2014 04:18 PM, Sebastian Rückerl wrote:
> Hello,
> 
> Lately I am playing around with some bash scripting that involves dd.
> 
> Everything seems to work fine as long as I am not trying to interrupt this 
> process (using CTRL-C).
> Only in this case everything just freezes for some time (for about 1 minute 
> the terminal is blocked) even if I try to kill it from another terminal using 
> its pid. This includes that all further CTRL-C are just printed to the 
> terminal and nothing happens.
> 
> My workaround now is to manage all the signal handling on my own. This seems 
> to work if my only goal was not to have the terminal beeing somehow not 
> responsive, but it does not kill the dd. (Which can still be seen using ps ax 
> | grep dd) Anyways dd is somehow interrupted (but not killed totally) as it 
> no longer responds to kill -USR1.
> 
> my current solution is:
> ----------
> #!/bin/bash
> 
> # some more things are done in the first place, not related to the dd
> 
> dd if=$1 of=$2 bs=4M &
> dd_pid=$!
> 
> control_c (){
>         echo "Aborting due to interrupt. Disk will most likely be useless."
>         kill -9 $dd_pid
>         exit 1
> }
> 
> # trap keyboard interrupt (control-c)
> trap control_c SIGINT
> 
> while   ps | grep " $dd_pid "
> do
>       # get some status information
>         kill -USR1 $dd_pid
>         sleep 3
> done
> 
> wait $dd_pid
> ret=$?
> # do some more error handling and continue with the script.
> ------------
> 
> the whole script is executed as root. $1 is a file (image of sd-card), $2 is 
> the path to the sd-card (e.g. /dev/sdc)
> 
> Can those (still somehow running) dd instances do any harm? Or are they just 
> waiting for something before they can be destroyed?
> 
> 
> Thank you for every answer that helps to clearify it all.

dd does catch ^C, but it processes pending interrupts before each read() and 
write(),
and those read() and write() calls should return with EINTR.

Therefore it seems like the kernel is blocking these signals?
Note I've seen the Linux kernel behave badly here, especially with slow devices,
where it caches too much before it starts writing out a lot of data
which then blocks other stuff. It caches based on free RAM rather than
on attributes of the sink device. This is a bug in the kernel IMHO.
You could avoid large parts of the Linux VM by using O_DIRECT:

  dd if=$1 of=$2 bs=4M oflag=direct

thanks,
Pádraig.