Use of the information contained in this unapproved document is at your own risk.

Last update: 20 April,2001

								1003.2-92  #149

 _____________________________________________________________________________


	Interpretation Number:	xxxx
	Topic:			sh and SIGTERM
	Relevant Sections:	6.1.6.1

Interpretation Request: (Defect Report)
-----------------------

	Date: Thu, 8 Aug 1996 15:25:34 +0100

I wish to ask for an interpretation request of the Shell and
Utilities standard, IEEE Std 1003.2-1992 (ISO/IEC 9945-2:1993)
related to signal handling by the shell. This issue
has been raised due to a test for a POSIX.2 test assertion.

To operate correctly, historically the shell has ignored SIGTERM for
shells that are deemed an interactive shell.  

Although POSIX.2 does not seem to discuss this issue, all shells we 
could check (ksh88, Bourne shell, ksh93, csh) are documented to 
ignore SIGTERM when they are interactive shells so that the 
command "kill 0" will not kill the login shell. We believe this
is valid for the POSIX shell as well.
	
To allow the "kill 0" for process group to have the desired
functionality a newly invoked utility needs to reset the disposition of
SIGTERM at startup and so introduces a race condition which is being hit
by this test case on systems which are fast (typically those with shells
that implement many common utilities by builtins).

The test suite assumes that a shell is interactive  - based on the 
page 414 of POSIX.2 lines 8852-8854:

	"if the -i option is present, or if there are no operands and the
	shell's standard input and standard error are attached to a terminal,
	the shell is considered to be interactive"

The test does not allow for the possibility of a race condition.
This problem can usually be duplicated by issuing the following
commands from an interactive shell:

        sleep 20 & kill %1

The "kill %1" doesn't terminate the "sleep 20" if the kill is
performed before the signal handlers are reset in the subshell
invoking the sleep.  

This may not work 100% of the time, because of the race for the child to start
and reset the disposition of SIGTERM before kill sends the signal; 
shells with builtin kill commands should demonstrate this most easily.

The actual test does the following:

sleep 300 & bg 2>/dev/null >/dev/null; cat - ; kill %1 2>/dev/null >/dev/null;

The following points are the important issues

1) all interactive shells need to handle/ignore SIGTERM.

2) jobs started by these interactive shells must reset the
disposition of SIGTERM at startup.

3) there is a race condition where the jobs may receive SIGTERM
after they are created but before they have had time to reset
SIGTERM's disposition.

4) VSC bg-17 test can hit that race condition, especially when the
shell is very fast with respect to "bg" and "cat", both of
which are builtins in our shell.
	   
Does a conforming shell have to delay continued processing
in the parent shell until the signal handlers in the asynchronous
list have been reset? 
	   
	
Interpretation response
------------------------
The standard clearly states the requirement sof execution
of asynchronous lists and conforming implementations
must conform to this.

The description of asynchronous lists in section 3.9.3.1 says that
the command terminated by the control operator & shall be executed
in a subshell. We believe that this means that the command runs
asynchronously with the parent shell, but not the creation of the
subshell, therefore the standard requires the sleep to be killed
in the example given.

If the phrase in 3.9.3.1 had stated that a subshell was created
asynchronously to execute the command the behaviour suggested would
be ok.

Rationale
-------------
None.

Forwarded to Interpretations group: Aug 9 1996
Forward for 30 day review: 22 Oct 1996
Finalised: 24 Nov 1996