SIGCONT occurs after a SIGTERM

[Blair P. Houghton]

In article <10007 at dog.ee.lbl.gov> torek at elf.ee.lbl.gov (Chris Torek) writes:
>In article <2519 at inews.intel.com> bhoughto at 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..."