java apache procrun 无法启动服务

apache procrun fails to start service

提问by Noah

EDIT

编辑

I am making use of the loaderDeamon interface to install and run a java app as a windows service. To do this, Apache's procrun service tool (same thing that gets installed with tomcat) handles the installation and execution of the service.

我正在使用 loaderDeamon 接口来安装和运行作为 Windows 服务的 Java 应用程序。为此，Apache 的 procrun 服务工具（与 tomcat 安装的工具相同）处理服务的安装和执行。

Recently when executing the service via the service manager, the service claims to be running, but does not respond. No log is written, and the client side of the app isn't able to communicate. This makes me think the service is not actually running.

最近通过服务管理器执行服务时，服务声称正在运行，但没有响应。不写入日志，应用程序的客户端无法通信。这让我认为该服务实际上并未运行。

I've attempted to launch the service via procrun by the //TS command as documented here: http://commons.apache.org/daemon/procrun.html, which hangs and hasn't started the service even if we wait up to 24 hours. The procrun itself generates a log that we've captured. The full log is included below. I have several questions about the log that I hope will clear up why the service doesn't start.

我试图通过 procrun 通过这里记录的 //TS 命令启动服务：http: //commons.apache.org/daemon/procrun.html，即使我们等待，它也挂起并且没有启动服务到 24 小时。procrun 本身会生成我们捕获的日志。完整的日志包含在下面。我有几个关于日志的问题，我希望能澄清为什么服务没有启动。

1. First, what does 'Java Worker thread finished... start with status=6' indicate on the termination of a thread?
2. Second, which threads are still executing when we get to the line 'Waiting for all threads to exit'?
3. Third, is there anything else in the log that stands out at potentially problematic when starting a service?

1. 首先，“Java Worker 线程完成……以 status=6 开始”表示线程终止是什么？
2. 其次，当我们到达“等待所有线程退出”这一行时，哪些线程仍在执行？
3. 第三，在启动服务时，日志中是否还有其他可能出现问题的内容？

This service has executed successfully in the past, and recently failed after an upgrade to java version 1.7.5. I reverted back to java 1.7.3 with to effect, so I believe the jvm change is unrelated, though worth mentioning.

该服务过去执行成功，最近升级到java 1.7.5版本后失败。我恢复到 java 1.7.3 以生效，所以我相信 jvm 更改无关紧要，但值得一提。

[2012-07-24 07:16:04] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized
[2012-07-24 07:16:04] [info]  ( prunsrv.c:1648) Commons Daemon procrun (1.0.10.0 32-bit) started
[2012-07-24 07:16:04] [debug] ( prunsrv.c:559 ) Installing service...
[2012-07-24 07:16:04] [info]  ( prunsrv.c:595 ) Service CProgramFilesx86XpressfeedLoaderV5serviceLoaderEngine name XF Engine - C:\Program Files (x86)\Xpressfeed Loader V5 service\Loader
[2012-07-24 07:16:04] [debug] ( prunsrv.c:611 ) Setting service description The Xpressfeed V5 loader engine, used in headless mode to run load jobs in the background.
[2012-07-24 07:16:04] [info]  ( prunsrv.c:629 ) Service 'CProgramFilesx86XpressfeedLoaderV5serviceLoaderEngine' installed
[2012-07-24 07:16:04] [info]  ( prunsrv.c:1729) Commons Daemon procrun finished
[2012-07-24 07:16:13] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized
[2012-07-24 07:16:13] [info]  ( prunsrv.c:1648) Commons Daemon procrun (1.0.10.0 32-bit) started
[2012-07-24 07:16:13] [info]  ( prunsrv.c:1545) Debugging 'CProgramFilesx86XpressfeedLoaderV5serviceLoaderEngine' service...
[2012-07-24 07:16:13] [debug] ( prunsrv.c:1345) Inside ServiceMain...
[2012-07-24 07:16:13] [info]  ( prunsrv.c:1089) Starting service...
[2012-07-24 07:16:13] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files (x86)\Java\jre7\bin\client\jvm.dll'
[2012-07-24 07:16:13] [debug] ( javajni.c:660 ) Jvm Option[0] -Djava.net.preferIPv4Stack=true
[2012-07-24 07:16:13] [debug] ( javajni.c:660 ) Jvm Option[1] -Djava.class.path=.;conf;dist\XpressfeedLoader.jar;lib\antlr-2.7.6.jar;lib\apache-log4j-extras-1.1.jar;lib\asm.jar;lib\auth\IA64\sqljdbc_auth.dll;lib\auth\x64\sqljdbc_auth.dll;lib\auth\x86\sqljdbc_auth.dll;lib\c3p0-0.9.1.2.jar;lib\cglib-2.2.jar;lib\commons-codec-1.4.jar;lib\commons-collections-3.1.jar;lib\commons-daemon-1.0.3.jar;lib\commons-dbcp-1.4.jar;lib\commons-lang-2.5.jar;lib\commons-logging-1.0.4.jar;lib\commons-pool-1.5.5.jar;lib\derby-10.6.2.1.jar;lib\dom4j-1.6.1.jar;lib\edtftpj-pro.jar;lib\freemarker.jar;lib\gui\jcommon-1.0.16.jar;lib\gui\jfreechart-1.0.13.jar;lib\hibernate-c3p0-3.5.2-Final.jar;lib\hibernate-tools.jar;lib\hibernate3.jar;lib\hsqldb.jar;lib\IAClasses.zip;lib\jargs.jar;lib\javassist.jar;lib\jaxen-1.1.1.jar;lib\jta.jar;lib\jtidy-r8-20060801.jar;lib\jung\collections-generic-4.01.jar;lib\jung\colt-1.2.0.jar;lib\jung\concurrent-1.3.4.jar;lib\jung\j3d-core-1.3.1.jar;lib\jung\jung-3d-2.0.1.jar;lib\jung\jung-algorithms-2.0.1.jar;lib\jung\jung-api-2.0.1.jar;lib\jung\jung-graph-i
[2012-07-24 07:16:13] [debug] ( javajni.c:660 ) Jvm Option[2] -Xms256m
[2012-07-24 07:16:13] [debug] ( javajni.c:660 ) Jvm Option[3] -Xmx1024m
[2012-07-24 07:16:13] [debug] ( javajni.c:880 ) DLL search path set to 'C:\PROGRA~2\XPRESS~2\jre\bin'
[2012-07-24 07:16:13] [debug] ( javajni.c:897 ) Java Worker thread started com/capitaliq/loader/loaderservice/LoaderService:start
[2012-07-24 07:16:13] [debug] ( javajni.c:914 ) Java Worker thread finished com/capitaliq/loader/loaderservice/LoaderService:start with status=6
[2012-07-24 07:16:14] [debug] ( prunsrv.c:1148) Java started com/capitaliq/loader/loaderservice/LoaderService
[2012-07-24 07:16:14] [info]  ( prunsrv.c:1244) Service started in 1160 ms.
[2012-07-24 07:16:14] [debug] ( prunsrv.c:1496) Waiting for worker to finish...
[2012-07-24 07:16:14] [debug] ( prunsrv.c:1501) Worker finished.
[2012-07-24 07:16:14] [debug] ( prunsrv.c:1524) Waiting for all threads to exit

Steps I've taken with no effect:

我采取的步骤没有效果：

1. Running the service at the console with debug
2. Specifying java SE versions 1.7.5, 1.7.3
3. Just using the default jvm 1.6.30, not specifying it
4. Extensive google work

1. 使用调试在控制台上运行服务
2. 指定 java SE 版本 1.7.5、1.7.3
3. 只使用默认的 jvm 1.6.30，不指定它
4. 广泛的谷歌工作

Any help or ideas appreciated! Thanks!

任何帮助或想法表示赞赏！谢谢！

采纳答案by Noah

After heavy use of the time-honed debugging strategy of commenting out stuff and running until it works, I eventually narrowed the problem down a recent upgrade of our log4jjars. We were running apache's log4j with the following versions:

在大量使用经过时间磨练的调试策略（注释掉内容并运行直到它起作用）之后，我最终将问题缩小到我们最近升级的log4jjars 中。我们使用以下版本运行 apache 的 log4j：

• apache-log4j-extras-1.0.jar
• log4j-1.2.16.jar
• slf4j-api-1.5.8.jar
• slf4j-log4j12-1.5.8.jar

• apache-log4j-extras-1.0.jar
• log4j-1.2.16.jar
• slf4j-api-1.5.8.jar
• slf4j-log4j12-1.5.8.jar

We upgraded to the following, which caused the problem:

我们升级到以下，这导致了问题：

• apache-log4j-extras-1.1.jar
• log4j-1.2.17.jar
• slf4j-api-1.6.6.jar
• slf4j-log4j12-1.6.6.jar

• apache-log4j-extras-1.1.jar
• log4j-1.2.17.jar
• slf4j-api-1.6.6.jar
• slf4j-log4j12-1.6.6.jar

After reverting back to the original jar files, the service was able to initialize and run without hanging.

恢复到原始 jar 文件后，该服务能够在不挂起的情况下进行初始化和运行。

Unfortunately, there was no stack or helpful errorproduced by the procrun logs (other than what I posted in the question), so I am unable to determine why log4j would conflict with initialization the service. If anyone else happens to know, I'm all ears - we will most likely be sticking with the older version of the jars until the unintended interaction is understood.

不幸的是，procrun 日志没有产生堆栈或有用的错误（除了我在问题中发布的内容），所以我无法确定为什么 log4j 会与初始化服务冲突。如果其他人碰巧知道，我全都在听 - 我们很可能会坚持使用旧版本的罐子，直到理解意外的交互。

回答by dfashimpaur

Recently, I had to try to get procrun to run my service as well. I found out after hours of trying to understand the issue that setting the --StdOutputand --StdErrorredirect parameters to auto. The stderr log gets generated in the --LogPathand contains the stack traces and other startup issues which cannot be seen in the standard Log file.

最近，我不得不尝试让 procrun 也运行我的服务。经过几个小时的尝试，我发现将--StdOutput和--StdError重定向参数设置为auto. stderr 日志在 中生成--LogPath并包含标准日志文件中无法看到的堆栈跟踪和其他启动问题。