guido@piring.cwi.nl (Guido van Rossum) (09/11/89)
The following puzzles me: if I start a background process with a shell escape from an editor (so the editor's shell escape command returns while the process remains in the background), and then suspend the editor wit ^Z, the background process dies. This happens in various editors (ed, vi), shells (csh, ksh) and OS versions (Ultrix 2.2 and 3.1, BSD 4.3tahoe, SunOS 4.0.3), to such diverse applications as sleep and xterm. A little test program shows that it dies of the SIGTSTP that is sent to the process group, which is strange because the man page for sigvec promises that the process will be suspended, not killed in this case (default signal action). The only explanation that I can find is that the kernel decides that since the process's parent has died, it makes no sense to suspend it; however, since it was started by a non-interactive shell (from the editor's shell escape), it is in the same process group as the editor from which it was (indirectly) started. Any gurus care to explain the reason for this behavior? -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net "You're so *digital*, girl!" -- Neneh Cherry
mouse@mcgill-vision.UUCP (der Mouse) (09/17/89)
In article <8397@boring.cwi.nl>, guido@piring.cwi.nl (Guido van Rossum) writes: > [ puzzle about backgrounding a job from a shell escape, then TSTPing > the program - the backgrounded process sees the TSTP and dies ] > A little test program shows that it dies of the SIGTSTP that is sent > to the process group, which is strange because the man page for > sigvec promises that the process will be suspended [...]. > The only explanation that I can find is that the kernel decides that > since the process's parent has died, it makes no sense to suspend it; > however, since it was started by a non-interactive shell (from the > editor's shell escape), it is in the same process group as the editor > from which it was (indirectly) started. From our 4.3 kern_sig.c: case SIGSTOP: case SIGTSTP: case SIGTTIN: case SIGTTOU: /* * These are the signals which by default * stop a process. */ if (action != SIG_DFL) goto run; /* * Don't clog system with children of init * stopped from the keyboard. */ If orphaned and sig > if (sig != SIGSTOP && p->p_pptr == &proc[1]) { is not STOP, send > psignal(p, SIGKILL); process a SIGKILL. p->p_sig &= ~mask; splx(s); return; } Why did they choose to do this? You got me. Perhaps someone found lots of stopped children of init lying around at some point? Perhaps some early getty was careless and let itself be stopped with t_suspc? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu