HELP! - why does this process die?

[terryl at tekcrl.UUCP]

In article <9 at houligan.UUCP> dave at murphy.UUCP (H. Munster) writes:
 >Help! I'm having a problem with a shell that keeps dying off at
 >inconvenient times.  Here's the situation: A user whose login shell is
 >csh runs a Bourne shell script; call this shell A.  Shell A is a menu
 >script which prompts for a function number and then executes shell B (as
 >a command, not "exec"), which runs shell C.  Both are Bourne shells. 
 >Shell C then runs shell D in background and exits to shell B, which also
 >exits, leaving the user back in shell A, which prompts for another
 >function.  Meanwhile, shell D does three things: it executes a bunch of
 >trap statements to ignore interrupt, hangup, and terminate; it runs a
 >program called "raster" which generates a plot on an electrostatic
 >plotter, and, when that finishes, it removes a lock file and then exits. 
 >
 >Now here's the problem: when the user is back in shell A, he gets impatient
 >and hits ^Z to suspend it so he can do other stuff while the plot is
 >running.  Trouble is, when ^Z is typed, shell D, which is waiting for the
 >raster process to complete, gets killed by something!  The raster process
 >is left still running without a parent (it gets inherited by init), but
 >since the shell D is dead, the lock file doesn't get deleted, and then
 >someone has to go remove it manually before anyone else can do a plot.
 >I can't seem to trap the signal that is causing shell D to terminate,

     The problem is that because shell C exits, it leaves D in the background
without a parent. Any process without a parent that receives the signal
SIGTSTP (which is what a <ctrl>-Z sends), or the signal SIGTTIN or SIGTTOU,
is silently killed by the kernel with a SIGKILL, which is why you can't trap
it.
with a SIGKILL