如果从Java启动，子进程将忽略SIGQUIT [英] Child process ignores SIGQUIT if started from Java

问题描述

以这个简单的例子为例:

 公共类Main{公共静态void main(String [] args)引发异常{Runtime.getRuntime().exec("sleep 1000");//这只是为了避免JVM退出Thread.sleep(1000 * 1000);}} 

我正在Linux上使用openjdk6运行它.如果我尝试向进程发送 SIGQUIT 信号，它将忽略它.其他信号( SIGINT ， SIGTERM 等)都可以正常工作，但是 SIGQUIT 被忽略.如果我只是在不使用Java的情况下从外壳运行 sleep 1000 ，那么 SIGQUIT 会得到正确处理.

为什么行为不同?

解决方案

向Java传递 -Xrs 选项.我已经测试了您的程序有无选项.如果没有该选项，则SIGQUIT将被阻止；有了它，当我向其发送SIGQUIT信号时，该信号就不会被阻塞并且睡眠过程会终止.

在

I am running this on Linux using openjdk6. If I try to send a SIGQUIT signal to the "sleep" process, it ignores it. Other signals (SIGINT, SIGTERM etc) all work fine, but SIGQUIT is ignored. If I just run sleep 1000 from a shell without using Java, then SIGQUIT is handled properly.

Why is the behaviour different?

解决方案

Pass java the -Xrs option. I have tested your program with and without the option. Without the option, SIGQUIT is blocked; with it, the signal is not blocked and the sleep process is terminated when I send it a SIGQUIT signal.

The closest explanation I can find about what's going on is in the OpenJDK 6 java(1) man page:

Sun's JVM catches signals to implement shutdown hooks for abnormal JVM termination. The JVM uses SIGHUP, SIGINT, and SIGTERM to initiate the running of shutdown hooks.

The JVM uses a similar mechanism to implement the pre-1.2 feature of dumping thread stacks for debugging purposes. Sun's JVM uses SIGQUIT to perform thread dumps.

Applications embedding the JVM frequently need to trap signals like SIGINT or SIGTERM, which can lead to interference with the JVM's own signal handlers. The -Xrs command-line option is available to address this issue. When -Xrs is used on Sun's JVM, the signal masks for SIGINT, SIGTERM, SIGHUP, and SIGQUIT are not changed by the JVM, and signal handlers for these signals are not installed.

这篇关于如果从Java启动，子进程将忽略SIGQUIT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！