Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: suspend question
Message-ID: <1647@mcgill-vision.UUCP>
Date: 17 Sep 89 01:43:31 GMT
References: <8397@boring.cwi.nl>
Organization: McGill University, Montreal
Lines: 45

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