Xref: utzoo comp.unix.questions:19614 comp.unix.wizards:20444
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Child processes ALWAYS die when parent killed?
Message-ID: <595@bbxsda.UUCP>
Date: 2 Feb 90 17:02:46 GMT
References: <22@dynasys.UUCP> <588@bbxsda.UUCP> <1869@ncrcce.StPaul.NCR.COM>
Reply-To: scott@bbxsda.UUCP (Scott Amspoker)
Organization: Basis International,  Albuquerque, NM
Lines: 28

In article <1869@ncrcce.StPaul.NCR.COM> mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) writes:
>In article <588@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>: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.  

I beg to differ - they certainly do.  If a program does a fork() and
an exec() without making arrangements to ignore keyboard interrupts
then the child process will receive those interrupts as long as it
is in the same process group.  (I should know - we had such a bug in
our software at one point in time causing a pipe to be broken :-).
If you launch a background process from the shell (with the '&' 
terminator) then the background child process will not receive keyboard
interrupts only because the *shell* set it up that way - not because
of the way signals are handled.  (Disclaimer: I'm speaking from the
Xenix documentation).

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