Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!tektronix!tekcrl!terryl
From: terryl@tekcrl.UUCP
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: HELP! - why does this process die?
Message-ID: <1219@tekcrl.UUCP>
Date: Sun, 23-Nov-86 03:17:37 EST
Article-I.D.: tekcrl.1219
Posted: Sun Nov 23 03:17:37 1986
Date-Received: Mon, 24-Nov-86 01:09:18 EST
References: <9@houligan.UUCP>
Reply-To: terryl@tekcrl.UUCP (Terry Laskodi)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 28
Xref: watmath comp.unix.questions:159 comp.unix.wizards:156

In article <9@houligan.UUCP> dave@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