SIGSTOP and SIGCONT rules

[Jerre Bowen]

Article 4157 of comp.sys.sgi:
Path: odin!shinobu!sgi!decwrl!ucbvax!ucsfcgl!babar.mmwb.ucsf.edu!srp
From: srp at babar.mmwb.ucsf.edu (Scott R. Presnell)
Newsgroups: comp.sys.sgi,comp.unix.wizards
Subject: SIGSTOP and SIGCONT rules
Summary: SIGSTOP and SIGCONT, what are the rules?
Keywords: signal, process groups
Message-ID: <srp.649092917 at babar.mmwb.ucsf.edu>
Date: 27 Jul 90 15:35:17 GMT
Sender: daemon at cgl.ucsf.edu
Distribution: usa
Lines: 27
Xref: odin comp.sys.sgi:4157 comp.unix.wizards:7768

Scott Presnell writes:

> 	I have been experementing with sending processes SIGSTOP
> and SIGCONT from csh.  This is under IRIX 3.2 - and assuming that I (not
> root) am doing the "kill"ing:
> 
> 	When a process is started and backgrounded from csh, I can
> basically STOP and CONT it from that csh or any other csh connection.
> Fine.
> 
> 	If I background the process and logout of the csh that started the
> process, then the first time I send it STOP from another csh, the process
> exits.
> 	
> 	What are the rules for sending SIGSTOP and SIGCONT to a process?
> From csh?  From a daemon that nolonger has a controlling tty?  (I'm more
> interested in the daemon rules.)  How does the process group relate to this?

	
	Signals have always been complicated, and were made more so with
the addition of job control.  First, there are a strict set of rules
governing which processes may signal which (unless the signaler is root).
See the various signal and kill man pages--generally no one but root may
signal daemons, because they are usually in pgrps by themselves.

	The SIG{STOP,TSTP,TTIN,TTOU} signals are job control signals, and
affect processes differently than some of the others.  You found that
you could start and stop background processes from the csh that spawned
them, but when you terminated the csh you could no longer do so.  That is
because all of csh's children were inherited by init (proc 1)--they must
still have a parent--but stop signals must then be treated differently
because init will never issue a SIGCONT: stopped children must be viewed
by the kernel as stopped forever, and must be dealt with.  Therefore,
processes whose parent is init receive SIGKILL instead of the stop signal
they were sent.

	I haven't looked at BSD code lately, but I imagine stop signals
must be treated this way in that system also to avoid leaving a myriad 
of forever-stopped processes hanging around.

	Close scrutiny of the man pages will explain this all somewhat.

		Jerre Bowen