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
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
