srp@babar.mmwb.ucsf.edu (Scott R. Presnell) (07/27/90)
Hey all - 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? Thanks. - Scott -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet
jik@pit-manager.MIT.EDU (Jonathan I. Kamens) (07/28/90)
In article <srp.649092917@babar.mmwb.ucsf.edu>, srp@babar.mmwb.ucsf.edu (Scott R. Presnell) writes: |> 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. This is not my experience on my BSD 4.3 system, which implies that either your version of Unix does something funky with STOP AND CONT that 4.3 doesn't, or that the process to which you're sending the STOP signal does something funky that causes it to exit if it doesn't have a tty when it gets STOPped. I tested this by logging into my machine via telnet, typing "sleep 3000 &", logging out, and then STOPping and CONTing the process from another xterm window as the same user. |> 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? As far as I know (and I hope people will correct me if I'm wrong, because I would like to hear about it), there aren't really any "rules" for sending STOP and CONT to another process. They are treated like any other signals. If this isn't true under IRIX and/or SysV, I'd sure like to hear about it. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
bowen@wanda.asd.sgi.com (Jerre Bowen) (07/28/90)
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: <srp.649092917@babar.mmwb.ucsf.edu> 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
spencer@eecs.umich.edu (Spencer W. Thomas) (07/28/90)
Actually, the rules are not nearly as complicated as you imply. If you are not root, you can send signals to any process with the same uid. If you are root, you can send signals to any process. You can send SIGCONT to any process which is a direct descendent of your process (in addition to the above rule). If an orphan (a process whose parent is init (process 1)) receives a SIGTSTP, it will be killed instead. However, you can send SIGSTOP to an orphan and restart it later with SIGCONT [[Oops -- not true on the Iris. It is true on Suns and 4BSD systems.]] Process groups have nothing to do with it (unless you use the killpg function). -- =Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109 spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F)