Xref: utzoo comp.unix.questions:28626 comp.unix.internals:2028 comp.unix.wizards:24071
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!mejac!orchard.la.locus.com!fafnir.la.locus.com!fafnir.la.locus.com!richard
From: richard@locus.com (Richard M. Mathews)
Newsgroups: comp.unix.questions,comp.unix.internals,comp.unix.wizards
Subject: Re: SIGCONT occurs after a SIGTERM
Message-ID: <richard.666333628@fafnir.la.locus.com>
Date: 12 Feb 91 04:40:28 GMT
References: <7103@fs1.cam.nist.gov>
Organization: Locus Computing Corporation, Los Angeles, California
Lines: 29

coleman@cam.nist.gov (Sean Sheridan Coleman X5672) writes:

>Please explain to me why a SIGCONT is sent to a process after
>SIGTERM is sent to my process. It doesn't compute because TERM
>means to terminate the the process. I catch SIGCONT because I 
>do some reconnecting for serial drivers after my process is
>stopped from a cntl-Z. Below is a piece of the code and a
>some output from the program. 

This is yet another example of C Shell brain damage.  The shell thinks
it is going to do you a favor.  When it sends SIGTERM or SIGHUP it follows
it with a SIGCONT.  The "problem" that the shell is trying to solve is
that a signal sent to a stopped process won't get processed until the
process resumes -- since you apparently wanted the process to die, the
shell sends a SIGCONT just to make sure the process will be able to get
to your signal right away.  Wrong answer.  It doesn't solve the problem
in general for all signals, and it creates about as much confusion as
it tries to avoid.

The solution is don't catch SIGCONT.  Your SIGTSTP handler knows when
the program resumes anyway because the line after the "kill" which
caused it to suspend itself will not be reached until the program is
resumed.  Taking the code you have for SIGCONT, and putting it there
is the "normal" way to do things.

Richard M. Mathews			 Freedom for Lithuania
richard@locus.com				Laisve!
lcc!richard@seas.ucla.edu
...!{uunet|ucla-se|turnkey}!lcc!richard