Question

我正在经营Tanuki Wrapper（已经有很长一段时间了）。在生产中，它工作得很好，但在这几周内，我收到报告说包装过程（C代码）被挂起并且不会因为生产问题而死亡。

当我收到警报时，我看一下这就是我所看到的：

1）几个小时后，使用SIGKILL / 9杀死了子java进程

STATUS | wrapper | 2016/02/08 03:49:20 | JVM received a signal SIGKILL (9).

2）然后我看到wrapper.sh stop是由我的自定义内部观察程序进程重置它的问题，但是这正在进入无限循环，如下所述：code link

stopit() {
    [snip]
            kill $pid  
            [snip]

        # MY NOTE It never gets out of this, the kill doesn't work

        # We can not predict how long it will take for the wrapper to
        #  actually stop as it depends on settings in wrapper.conf.
        #  Loop until it does.
        savepid=$pid
        CNT=0
        TOTCNT=0
        while [ "X$pid" != "X" ]
        do
            # Show a waiting message every 5 seconds.
            if [ "$CNT" -lt "5" ]
            then
                CNT=`expr $CNT + 1`
            else
                eval echo `gettext 'Waiting for $APP_LONG_NAME to exit...'`
                CNT=0
            fi
            TOTCNT=`expr $TOTCNT + 1`

            sleep 1

            testpid
        done

      [ SNIP ] 
    fi
}

3）然后我登录到盒子并找到包装器进程pid（记住JVM已经死了）并发出直接kill $ pid，然后等待......什么都没有。 possible code?

4）最后放弃并发出kill -9 $ pid，最终杀死它，一切都清理干净并恢复活力。

问题：

如何解决使用kill $ pid（SIGTERM / 15）不起作用的应用程序的问题？这对于 YEARS 来说非常有用，并且仍然在很多其他过程中，但只有少数它失败了。

当然，Tanuki的大部分问题和文章都是关于如何操纵/询问孩子的JVM，但我实际上看到了我认为是C代码的问题而且我不确定如何查询挂起的PID代码以放弃密码。也许/proc/$pid中的某些东西可以告诉我它挂在哪里？

帮助我Obi-Wan Kenobi，你唯一的希望......

Answer 1

来自Tanuki Software的Leif

使用SIGKILL意外杀死JVM的最可能原因是操作系统资源不足并导致进程终止。发生这种情况时，Java通常是内存的最大用户，因此它会被钉死。请检查系统日志，因为如果是原因，应该同时输入一个条目。

即使发生了这种情况，Wrapper也应正确处理并重新启动JVM。听起来好像Wrapper已经陷入了意想不到的状态，并且没有对正常信号本身做出反应。你正在使用的Wrapper版本是什么？我仔细检查了发行说明，但不认为我们之前已经看过这个问题。 http://wrapper.tanukisoftware.com/doc/english/release-notes.html

请告诉我你在JVM被杀的时候在你的系统日志中找到了什么。

java服务包装器父进程挂起

1 个答案: