Child processes ALWAYS die when parent killed?

[Dan Mercer]

In article <588 at bbxsda.UUCP> scott at bbxsda.UUCP (Scott Amspoker) writes:
:In article <22 at dynasys.UUCP> jessea at dynasys.UUCP (Jesse W. Asher) writes:
:>I was curious as to whether all child processes die when the parent is
:>killed.  I seem to remember that sometimes you can get a whole string of
:>processes off of one parent, and under certain circumstances, when you
:>kill the parent, you don't necessarily kill all of its children.  It seems
:>it was something about the children switching parents or some such??  Does
:>anyone out there know what I'm talking about or am I just crazy?  Thanx in
:>advance.
:
:If a parent terminates, surviving children are adopted by 'init' (pid=1). 
:If a signal is used to kill the parent the same signal might also be sent 
:to the children (such as the break interrupt) giving you the impression that
:the children died because the parent died.  Normally, children should
:make arrangements to handle such signals especially when running in
:"background".

Processes running in background do not receive keyboard generated
interrupts.  

The promotion of a child's parent to init can be very annoying,
particularly if the child is a full screen,  raw i/o program like
vi.  One easy way to get into the situation is through make

x : x.c
	cc -g x.c -o x 2>&1 | error -v

If the compile fails,  the error messages will be inserted in x.c
by error and vi will be called.  If you hit the interrupt key while
in vi,  vi catches the interrupt and terminates its current operation
and displays an error message.  Make also catches the interrupt and
goes through termination processing.  You wind up with two processes -
vi and sh - with init as parent.  You also have two processes competing
for input.  Democratically,  they each get every other character.  Your
tty settings may also be munged (cr not changed into lf for instance).
It is left to the student to figure out how to get out of this
predicament.  (no fair screaming insults at your tube or having your session
cancelled.  In fact,  I would expressly advise against using Control-d
in this situation,  unless you are fond of having getty and vi competing
for your input at the same time,  or of having two gettys run against the
same line).

The easiest way to avoid this is to disable the interrupt keys - saving
off the stty settings into a variable - disabling the interrupt key
with a second tty - do the compile - restore the stty setting.

I have done it,  but then thought of a neater idea - I'd divorce the
new process from the controlling terminal by running setpgrp on it.
And it works,  kind of.  Interrupts no longer get passed to make.  But
that's because they're no longer generated by the child process.
Oh, well!

:
:-- 
:Scott Amspoker
:Basis International, Albuquerque, NM
:(505) 345-5232
:unmvax.cs.unm.edu!bbx!bbxsda!scott


-- 

Dan Mercer
Reply-To: mercer at ncrcce.StPaul.NCR.COM (Dan Mercer)