Re: Problem using dd within bash script

[Sebastian Rückerl]

On Sat, Apr 26, 2014 at 11:41:45AM -0600, Bob Proulx wrote:
> Pádraig Brady wrote:
> > Sebastian Rückerl wrote:
> > > 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.
> >
> > 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?
> 
> I was thinking the same thing.  I was thinking that the dd process
> must be in the kernel blocked queue waiting for I/O.  That is why it
> doesn't exit quickly after being sent kill signals.  Processes blocked
> waiting for I/O aren't actually "running" at that moment and therefore
> can't handle the signal and can't die in the normal sense until the
> I/O completes and they get back into the run queue and runs.
> 
> > > Can those (still somehow running) dd instances do any harm? Or are
> > > they just waiting for something before they can be destroyed?
> 
> Those processes that are still there after you try to kill it have
> performed a read(2) or write(2) operation and are waiting on the
> kernel to return control to them.  There isn't anything that can be
> done outside of the kernel to change their state.  The programs are
> not actually "running" as control has been passed to the kernel to
> perform the I/O.  As soon as the kernel finishes the write(2) and
> returns to the program then the program will handle the signal and
> exit.
> 
> > 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.
> 
> Yes.  And people tuning systems often do the opposite of what I think
> should be done.  It is really hard to do good optimization without
> objective benchmarks to provide data.
> 

First of all think you for this explanation. If I got it right this is related 
to
unfinished operations, which would explain this behaviour. 

> > You could avoid large parts of the Linux VM by using O_DIRECT:
> >
> >   dd if=$1 of=$2 bs=4M oflag=direct
> 
> Good suggestion!
> 

This really helps to keep the delay low between pressing CTRL-C and the exit of 
my
script. But it feels as if this would slow down the whole process.
But if I got it right this is just my feeling as I would have to wait the time
at the next sync (or the unmount which should sync, too). So the total amount of
time needed to perform the whole thing (copy + sync ) should still be the same.

I think I might try this at some point in the future. But in this case it's not 
about
speed but about a working script to do my work. No matter if it's a little bit 
slower
than it could be in a perfect case.

> > > 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
> 
> In your trap handler don't 'exit 1'.  That washes off the correct exit
> code.  Instead reset your trap handler to the default handler and then
> send the kill signal back to the current process.  That will cause it
> to exit with the correct, kill on signal, information.
> 
>   control_c (){
>           echo "Aborting due to interrupt. Disk will most likely be useless." 
> 1>&2
>           kill -9 $dd_pid
>           trap '' INT
>           kill -s INT $$
>   }
>   
>   # trap keyboard interrupt (control-c)
>   trap control_c SIGINT
> 

Is this really a big deal as the next process (the one calling this script) is 
the
bash / myself starting it on the command line? So is this something that is
generally important for scripting? I must admit, I have never thought about it.

signature.asc
Description: Digital signature