mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (02/02/90)
In article <588@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: :In article <22@dynasys.UUCP> jessea@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@ncrcce.StPaul.NCR.COM (Dan Mercer)
scott@bbxsda.UUCP (Scott Amspoker) (02/03/90)
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