JDK-4840407 : Ctrl-C in linux/sunOS is killing the foreground process and all of its children
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2003-04-01
  • Updated: 2003-04-29
  • Resolved: 2003-04-29
Related Reports
Relates :  
Description
This looks to be broken in 1.4.2-b19 build with latest CTRL+C changes. May be a regression.  

Name: nt126004			Date: 03/31/2003


FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)


FULL OS VERSION :
Linux (SuSE 2.4.18-4GB)
SunOS 5.9

A DESCRIPTION OF THE PROBLEM :
When executing a process with Runtime.getRuntime().exec() in a linux or solaris environment, if the parent process is running in foreground and you hit 'Ctr-C' both processes are terminated, although this doesn't happen if the father process is killed by sending any of SIGKILL, SIGINT or SIGTERM signals

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
-Compile and execute the attached code without any arguments
-Check with ps that there are two processes
-Send a kill -2 (SIGINT) to the parent process (the same can be tested with SIGKILL, SIGQUIT and SIGTERM)
-Verify with ps that the child is still running (proper behaviour)
-Kill the children process
-Execute the father again
-Verify both processes are created
-Having the father process in foreground, hit Ctrl-C

EXPECTED VERSUS ACTUAL BEHAVIOR :
The child process should keep running
Both processes are terminated

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.IOException;

public class JDKProcessExecutionTest
{

    public static void main(String[] args)
    {
        if (args.length > 1) {
            //children
            for(;;) {
                System.out.println(" children! ");
                try {
                    Thread.sleep(30 * 1000);
                }
                catch (InterruptedException e) {
                    //just ignore...
                }
            }
        }
        else {
            //father

            try {
                Process p = Runtime.getRuntime().exec("java -cp . JDKProcessExecutionTest create child");

                for(;;) {
                    System.out.println(" father! ");
                    try {
                        Thread.sleep(30 * 1000);
                    }
                    catch (InterruptedException e) {
                        //just ignore...
                    }
                }
            }
            catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}
---------- END SOURCE ----------
(Review ID: 182937) 
======================================================================

Comments
EVALUATION Appears to be a duplicate of a bug just putback to b19 or future b20 build. ###@###.### 2003-04-03 This looks to be broken in 1.4.2-b19 build with latest CTRL+C changes. May be a regression. Looked at history files and it appears this chnage made it back to b19, but this is still failing. ###@###.### 2003-04-03 I've checked 1.4.1 FCS and 1.3.1_b24 (I think thats FCS), and the problem persists there also. I don't think this is a bug. This is the classical parent child relationship. The parent process forks off a child process and it retains the same signal disposition as the parent. When a signal is delivered to the parent in the foreground I would expect that it would also be delivered to the child process. In this case SIGINT should kill the child process. However if the process is in the background, it is immune to signals sent to its parent process (ie: the shell) Please outline why you think that the child process should not recieve the signal. ###@###.### 2003-04-03 Customer response via JDC comments (2003-04-04): "However if the process is in the background, it is immune to signals sent to its parent process (ie: the shell)" I agree, but in this case, the signal is sent to the process in background (not to the parent shell) and it's not delivered to its children. Removed incomplete status. ###@###.### 2003-04-29 The bug states that the problem is that when CTRL-C is sent to a foreground process, all of its children are killed. This is normal behaviour, hence this is not-a-bug. OK lets deal with sending a signal to a background process. When a new process is forked, it is created in the same process group as its parent. When user presses Ctrl-C, shell is responsible to send SIGINT to every process in the forground process group. So both parent and child should receive SIGINT as a result of Ctrl-C. But if you do "kill -INT pid", the signal is only delivered to that particular process. I'm going to close this bug as not-a-problem. ###@###.### 2003-04-29
29-04-2003