1、背景描述

某日某客户运维工程师接收到系统报障反应业务缓慢，工程师用命令kill -3 < WLS_PID >的方式发送一个SIGQUIT信号给Java应用之后，通常会有当前的Thread Dump输出，最后thread dump信息没有收集出来，相反weblogic进程自动退出，导致服务停止，业务无法正常工作。

2、系统环境

操作系统： Redhat6.4
JDK版本： JDK1.6
中间件版本：weblogic10.3.6
集群：否

3、故障处理过程

3.1、故障分析

2016-09-13 15:23左右，客户现场运维工程师接收到报障反应系统访问相当慢，于是运维工程师立即检查中间件运行情况，并做了一下线程转储收集。在做线程转储收集时候，服务被终止。现场工程师说当时执行了kill -3 这条命令来收集thread dump信息，没想到竟然把weblogic服务进程给杀掉了。他说以前平时常用kill -3来收集线程信息，今天竟奇怪的把服务给干掉了。他也反复确认操作的命令没错。

发现故障时间15:24产生了一个core dump文件，应该是kill -3信号产生的文件

分析产生的core文件，没有找到完整的信息

联想起以前处理过类似问题，weblogic进程自动退出。不想要操作系统调用正在终止JVM进程。当某个组件将不正确的关闭信号发送到JVM时会发生此问题。然后，JVM捕获这些信号，并关闭所有JAVA进程。

当时解决这个问题方法是，将-Xrs参数添加到标准WebLogic启动脚本中的JAVA_OPTIONS启动参数中。

为什么要加-Xrs参数的原因？

参数-Xrs是为了避免JVM对操作系统信号的使用。这个参数告诉JVM不要为许多事情使用任何操作系统信号，而是依靠加载应用程序（启动器）来处理TERM，INT; HUP和QUIT。如果JVM作为服务运行，它可以接收CTRL_LOGOFF_EVENT，但不应该启动关闭，因为操作系统不会实际终止进程。

回过头来检查domain下的启动环境变量脚本，发现2016-09-07 22:23这个时间点setDomainEnv.sh环境变量脚本有改动过，而且在JAVA_OPTIONS变量后确实加入了参数-Xrs.

经过自己在几个不同版本测试环境下测试，加了这个-Xrs参数确实用kill -3会把服务进程杀死。不加这个-Xrs参数用kill -3不会把进程杀死，也能够收集thread dump信息

3.2、故障原因

将-Xrs参数添加到标准WebLogic启动脚本中的JAVA_OPTIONS启动参数中，如果用kill -3命令去收集thread dump信息，直接会触发操作系统信号杀掉服务进程。

3.3、解决方法

1、由于大家常用习惯用kill

-3命令来收集线程转储信息，导致出现这样的问题。记住以后在生产系统kill尽量不用，不管kill后面带什么信号参数，不建议在生产环境上面执行。

以下是抓取thread

dump常用方法

1）JVM自带的工具获取线程堆栈:

$JAVA_HOME/bin/jstack wls_pid

2）WebLogic自带的获取thread dump的工具:

/bin/setDomainEnv.sh

$JAVA_HOME/bin javaweblogic.Admin -url t3://localhost:9001 -username weblogic -password weblogic1THREAD_DUMP

3）使用utils.ThreadDumper

java -cpC:\bea\wlserver_10.3\server\lib\weblogic.jar utils.ThreadDumper

4）使用weblogic console方法生成

a.登录Admin Console ,点击对应的服务器

b.点击Server à Monitoring àThreads

c.点击: Dump Thread Stack按钮

5）使用WLST工具

java weblogic.WLSTthreaddump.py

欢迎大家关注我的微信公众号，里面有很多相关的技术干货，也能随时联系到我。谢谢！

（完）

Weblogic接收SIGQUIT信息号引发服务中止故障