SIGCONT occurs after a SIGTERM
Sean Sheridan Coleman X5672
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.
Here I stop the program with a ^Z and restart using fg %1.
SIGCONT is sent in this situation correctly.
<deputy /home/central/coleman/real_prog/net.dir/net_log> % net l logfile
^Z Signal caught is 18
Stopped (signal)
<deputy /home/central/coleman/real_prog/net.dir/net_log> % jobs
[1] + Stopped (signal) net l logfile
<deputy /home/central/coleman/real_prog/net.dir/net_log> % fg %1
net l logfile
Signal caught is 19
^C Signal caught is 2
From another window, I used kill -TERM to kill this process.
SIGTERM is received first but then SIGCONT is sent for no known
reason.
<deputy /home/central/coleman/real_prog/net.dir/net_log> % !ne
net l logfile
Signal caught is 15
Signal caught is 19
No devices are available to use for logging
Here is the signal handler:
Note: device,device_file and device_name are global
sig_handler(sig)
int sig;
{
extern int device;
extern FILE *device_file;
extern char *device_name;
char *strip_add_dev_name();
printf(" Signal caught is %d\n",sig);
switch(sig)
{
case SIGINT:
case SIGTERM:
unlock_dev(strip_add_dev_name(ttyname(device),0));
exit(1);
case SIGTSTP:
unlock_dev(strip_add_dev_name(ttyname(device),0));
close(device);
kill(0,SIGSTOP);
break;
case SIGCONT:
if(device_file != NULL)
{
rewind(device_file);
device = get_device(device_file);
}
else
{
if((device = chk_device(device_name)) < 0)
{
printf("No devices are available to use for logging\n");
exit(1);
}
}
default:
break;
}
}
Thanks
Sean Coleman
col...@bldrdoc.gov
NIST
Boulder, CO
Richard M. Mathews
>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
ric...@locus.com Laisve!
lcc!ric...@seas.ucla.edu
...!{uunet|ucla-se|turnkey}!lcc!richard
Edward Conger
>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.
The distinction is that sending a signal to a process (usually|often)
is implemented by setting a bit in a flag word associated with the
"victim process". The action of *send*ing the signal doesn't
terminate the process, rather, it says, "when next you run in the
kernel (either via a system call or a timeslice (usually ~ 1/100 sec)),
you should go handle this signal." In the case of SIGTERM, the default
behaviour is to TERMinate.
Now suppose the victim process is stopped (either by job control, SIGSTOP,
or via debugging), it will NOT see the bit set in the flag word until it
runs again. The SIGCONT gets it unstopped and it runs long enough to
terminate.
Your mileage (and implementation) may vary, but this is the general gist of
the problem.
>Thanks
>Sean Coleman
>col...@bldrdoc.gov
>NIST
>Boulder, CO
>----------
Hope this helps,
-Ed.
===========================================================================
The above is an official statement of MeMyself & I Inc. It should not
be interpreted to be an official statement of any other likely targets,
including, but not limited to, Hewlett-Packard Co., ACME Rockets, ACME Rubber
Bands, ACME Consolidated Mining Engineering, or the Home for Damaged Coyotes.
Heiko Blume
>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.
which fails miserably when you get the uncatchable SIGSTOP.
*yes*, i do use SIGSTOP, there are programs that disable
the SIGTSTP feature, and i won't let those go unsuspended.
--
Heiko Blume <-+-> s...@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
public source archive [HST V.42bis]:
scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
uucp scuzzy!/src/README /your/home
Brandon S. Allbery KB8JRR
+---------------
| 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
Being suspended, it wouldn't execute the signal handler unless it were
continued. Also, I think the exit processing in the kernel needs this.
(So why does the SIGCONT handler run after the SIGTERM handler? Because
signal handlers are invoked in signal-number order.)
++Brandon
(BSD folks feel free to correct me.)
--
Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440
Internet: all...@NCoast.ORG Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
Blair P. Houghton
>The SIGCONT gets it unstopped and it runs long enough to
>terminate.
>Your mileage (and implementation) may vary, but this is the general gist of
>the problem.
Not the least of those variances is that signals may be
queued, so that the SIGCONT may simply be waking the
process up only to watch it go to sleep again (unless the
SIGTERM can somehow butt into the queue).
--Blair
"Dave? Dave's not here..."
Chris Torek
(Blair P. Houghton) writes:
>Not the least of those variances is that signals may be queued ....
Signals are not queued.
As far as I know, there is only one piece of one Unix manual that
claims otherwise (that being the System V SIGCLD documentation), and it
lies. Signals are never queued. System V SIGCLD signals use a
different trick that causes properly-coded wait routines to be called
once per exited child, but which causes improperly-coded wait routines
to recurse indefinitely.
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA Domain: to...@ee.lbl.gov
Blair P. Houghton
>In article <25...@inews.intel.com> bhou...@pima.intel.com
>(Blair P. Houghton) writes:
>>Not the least of those variances is that signals may be queued ....
>
>Signals are not queued.
Something's stacking them up.
I've run into situations more than once where I've tried to
stop a process and the stop has hung, usually due to
something else's being stuck (an NFS access, e.g.) I've
sent the stop again, and when the block clears I see the
process stop. When I tell the process to continue, the
first thing it does is stop itself again.
Who's doing it? The kernel or csh(1)? The tty driver? Or
is it just a matter of a stuck process queue? I can't
imagine all the kills not being done by the time I've typed
in the command to continue...
--Blair
"It also happens under VMS,
but I'll keep mention of that
'Fine' system to a minimum..."
Larry McVoy
>In article <10...@dog.ee.lbl.gov> to...@elf.ee.lbl.gov (Chris Torek) writes:
>>Signals are not queued.
>
>Something's stacking them up.
>
There is a one deep stack for signals. I think that Chris meant to say that
multiple instances of the same signal will all get coalesced into one as
long as the signal has not yet been delivered.
Think of Unix as a virtual processor, system calls are instructions, and
signals are interrupts. In a processor, noone stacks interrupts. The
only promise is that one of N will get delivered, N - 1 are all lost.
---
Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or l...@sun.com