0

我正在运行 Tanuki Wrapper（并且已经运行了很长时间）。在生产中，它运行良好，但在那几周内，我收到报告称包装器进程（C 代码）已挂起并且不会死亡，这会导致生产问题。

当我收到警报并查看时，我看到的是：

1) 几个小时前，子 java 进程被 SIGKILL/9 杀死

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

2）然后我看到wrapper.sh stop我自定义构建的内部观察程序重置它时出现问题，但这正在进入一个无限循环，如下所述：代码链接

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，然后等待......什么都没有。可能的代码？

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

问题：

如何对 kill $pid (SIGTERM/15) 不起作用的应用程序进行故障排除？这在YEARS中效果很好，并且仍然在许多其他过程中，但在少数几个过程中它失败了。

当然，关于 Tanuki 的大多数问题和文档都是关于如何操作/询问子 JVM，但我实际上看到了我认为是 C 代码的问题，我不确定如何询问挂起的 PID放弃秘密的C代码。也许里面的东西/proc/$pid可以告诉我它挂在什么上面？

帮助我欧比旺克诺比，你唯一的希望......

4

1 回答 1

3

来自 Tanuki Software 的 Leif

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

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

请让我知道您在 JVM 被杀死时在您的系统日志中发现了什么。

于 2016-02-10T03:03:27.337 回答