signal propogation to backgrounded subshells

[Jeff Weber]

I have a situation whereby my script may encounter commands which may block 
for a "long time", before completion.  However, for other reasons, my initial 
script must complete "quickly".

My solution has been to encapsulate the blocking commands in a subshell, then 
run the subshell in the background.  Thus the parent script can complete 
quickly.

The background subshell needs to execute a serial list of commands.  (During 
script development, I am using sleep to mimic blocking commands.)

The problem occurs when trying to cleanup the backgrounded subshell, if it is 
still active.  I would like to be able to send a signal to the subshell, 
which would terminate the subshell and all active subshell commands.  This is 
not the behavior I am seeing.

Rather, I am seeing the subshell bash process terminate, but the currently 
active subshell child process continues to execute, with a new parent pid of 
1 (init). That is, the signal kills the subshell, but not the active subshell 
child process.   Again, I want every process associated with the subshell to 
die upon receipt of the signal.

Here's some sample code:

# create a backgrounded subshell to execute long-running processes
#( sleep 300 && sleep 400 && sleep 500 )&       # doesn't work, bummer
$SHELL -c "sleep 300; sleep 400; sleep 500" &   # doesn't work, bummer
pid=$!
echo background job $pid


When I run this, it announces the background job pid, which I then kill.  I've 
tried SIGHUP, SIGINT, SIGTERM.  The backgrounded bash job terminates as 
expected.  However, the active sleep job continues to execute, now being 
owned by init.  Somehow, it "escaped".  I want any active sleep job to die 
too.

Is this a bug, feature, or misunderstanding?  Regardless, is there a simple 
solution to get the behavior I want?

config:
GNU bash, version 3.1.17(1)-release (i586-suse-linux)
Copyright (C) 2005 Free Software Foundation, Inc.

        TIA,
        Jeff Weber