[net.unix-wizards] 4.2BSD signal question

discolo@ucsbcsl.UUCP (Anthony V. Discolo) (08/30/84)

A friend of mine had an interesting problem with signals.  He has a
program that catches SIGHUP and SIGQUIT.  When the process is stopped,
sending it a SIGHUP will restart it, but sending it a SIGQUIT will not
restart it.  The SIGQUIT signal is received when the process is 
restarted, either by a SIGQUIT, or by a SIGCONT.

For example, a.out continuously prints periods, it will print an H
when it receives a SIGHUP, and it will print a Q when it receives
a SIGQUIT.  The following is a script that should explain the situation.
My comments are within {}.

			% a.out > OUT
			^Z
			Stopped
			% cat OUT
			......................
			% cat OUT
			......................
			{ a.out is stopped and is not printing
			periods at this time }
			% jobs
			[1] + Stopped		a.out
			% kill -HUP %1
			% cat OUT
			......................H.........
			% cat OUT
			......................H......................
			{ a.out has received the SIGHUP, and has
			been restarted }
			% jobs
			[1] + Stopped		a.out
			{ csh doesn't know that the process has been 
			restarted }
			% fg
			^Z
			Stopped
			% kill -QUIT %1
			% cat OUT
			......................H..........................
			% cat OUT
			......................H..........................
			{ a.out has not received the SIGQUIT yet, and has
			not been restarted }
			% fg
			^Z
			% cat OUT
			......................H..........................Q...
			% cat OUT
			......................H..........................Q..........
			{ now a.out has received the SIGQUIT and is running }

Can someone please explain to me in detail why this is so?  I've briefly
searched the source code, but haven't found an explanation.

Please reply by mail, and I'll post satisfactory explanations.
-- 

uucp: ucbvax!ucsbcsl!discolo
arpa: ucsbcsl!discolo@berkeley
csnet: discolo@ucsb
USMail: Computer Systems Lab
	U.C. Santa Barbara
	Santa Barbara, CA  93106
GTE: (805) 961-3221

discolo@ucsbcsl.UUCP (08/30/84)

I have solved my own question about why SIGTERM and SIGHUP
continue a stopped process, while the other signals do not.
I quote from the UPM entry for csh(1) pp. 12:

	"kill ...
		... If the signal being sent is TERM (terminate)
		or HUP (hangup), then the job or process will be
		sent a CONT (continue) signal as well."

My new question is why is QUIT not included with TERM and HUP,
since the probable reason this is done is to cause immediate
response to an urgent condition?

Could the reason be tradition?
-- 

uucp: ucbvax!ucsbcsl!discolo
arpa: ucsbcsl!discolo@berkeley
csnet: discolo@ucsb
USMail: Computer Systems Lab
	U.C. Santa Barbara
	Santa Barbara, CA  93106
GTE: (805) 961-3221

dmmartindale@watcgl.UUCP (Dave Martindale) (09/03/84)

One possible rationale for why sending TERM and HUP to a process generate
automatic CONT signals while QUIT does not:

The INTR and QUIT signals are normally generated from the keyboard and
sent only to the "foreground" process group, which is executing.
There should be no need to send a CONT.  TERM and HUP, on the other
hand, are often sent to "background" processes because you want to
get rid of them, or the system is going down, or your phone line just hung
up - in these cases you want the process to un-suspend so it can clean
up and die.