coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem using dd within bash script


From: Sebastian Rückerl
Subject: Re: Problem using dd within bash script
Date: Tue, 29 Apr 2014 09:22:20 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Apr 28, 2014 at 12:40:00PM -0600, Bob Proulx wrote:
> Sebastian Rückerl wrote:
> > Bob Proulx wrote:
> > > 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.
> 
> >          trap '' INT
> >          kill -s INT $$
> 
> First, I made a mistake and it needs a correction.  I typed that in
> when translating to your example but '' ignores the signal.  We don't
> want to ignore it.  We want to set it to the default handler.  That
> should be - instead.  A big mistake.  It should be:
> 
>          trap - INT
>          kill -s INT $$
> 
> My example that I usually use is:
> 
>   unset tmpfile
>   cleanup() {
>     test -n "$tmpfile" && rm -f "$tmpfile"
>   }
>   trap "cleanup" EXIT
>   # Begin dash specific trap handling.
>   trap "cleanup; trap - HUP; kill -HUP $$" HUP
>   trap "cleanup; trap - INT; kill -INT $$" INT
>   trap "cleanup; trap - QUIT; kill -QUIT $$" QUIT
>   trap "cleanup; trap - TERM; kill -TERM $$" TERM
>   trap "trap - PIPE; cleanup; kill -PIPE $$" PIPE
>   # End dash specific trap handling.
>   tmpfile=$(mktemp) || exit 1
> 
> > 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.
> 
> I think it is a big deal.  It is one of slack culture.  It isn't the
> correct thing to do.  Yet we have all seen it done many times.  And so
> the problem continues and continues.  The only way to stop that
> culture is to educate as to the problem so that it becomes the culture
> to always handle signals correctly.
> 
> Have you ever seen a script that includes a loop and when you
> Control-C to interrupt it the script does not stop?  It cycles around
> the loop again and does not interrupt.  You end up holding down the
> Control-C key to give many key-repeated interrupts.  Eventually one of
> them gets through and the script exits.  It just does not behave
> correctly.  That is an example incorrect signal handling causing
> trouble.  If signals were handled properly then one interrupt would
> always be sufficient.
> 
> A good article explaining this in detail.
> 
>   http://www.cons.org/cracauer/sigint.html
> 
> Bob

So after some more playing around I found out that oflag=direct is the
solution to avoid the long waiting time between killing the dd and the
real exit (it buffered about 500MB to 1GB within the OS which of course
took a while to write out to a slow SD-Card).
Here is my final code which seems to work now.
I hope I fixed the interrupt issue the way it should be done. I'll
definitly keep that in mind for the future. First hand I just didn't
see the consequences of not handling the interrupts that way.



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

control_c (){
        echo "Aborting due to interrupt. Disk will most likely be useless."
        kill -s KILL $dd_pid
        trap - INT
        kill -s INT $$
}
#
# trap keyboard interrupt (control-c)
trap 'control_c' INT

while   ps ax | grep " $dd_pid "     # might also need  | grep -v grep  here
do
        kill -s USR1 $dd_pid
        sleep 5
done

wait $dd_pid
ret=$?
if [ $ret -ne 0 ]; then
        echo "Error while copying Image to disk"
        exit 1
fi
trap - INT




Thanks for your help & have a good day,
Sebastian

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]