Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!sdd.hp.com!decwrl!sgi!shinobu!odin!bowen@wanda.asd.sgi.com From: bowen@wanda.asd.sgi.com (Jerre Bowen) Newsgroups: comp.sys.sgi Subject: Re: SIGSTOP and SIGCONT rules Message-ID: <11074@odin.corp.sgi.com> Date: 28 Jul 90 00:52:43 GMT Sender: news@odin.corp.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 58 Article 4157 of comp.sys.sgi: Path: odin!shinobu!sgi!decwrl!ucbvax!ucsfcgl!babar.mmwb.ucsf.edu!srp From: srp@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: Date: 27 Jul 90 15:35:17 GMT Sender: daemon@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