Tomcat重新启动时出错(退出143),运行然后失败

时间:2016-10-20 18:09:02

标签: java tomcat8 mysql-connector exit-code broken-pipe

这是我第一次在Stack Overflow上提问。我最近配置了一个Ubuntu 16.04虚拟专用服务器来托管Web应用程序。我在一个读取和写入MySQL数据库的Tomcat服务器上运行ngnix。该应用程序运行正常,除了Tomcat偶尔重启自身这一事实导致500错误源于"破坏管道"当有人试图登录(即建立与数据库的连接)。 我会在下次发布时发布500的图像。我进入了我的vps并查看了我的Tomcat重启消息。这就是我看到的: Tomcat status message.

我也对Tomcat日志进行了一些深入研究,这是一个与重启时间相对应的日志文件: Tomcat log file

我做了一些研究试图自己解决这个问题,但没有成功。我认为exit = 143是由另一个程序或系统本身终止的进程。我也做了一些mysql-connector-java.jar的移动。我读到它应该位于Tomcat / lib目录中,而不是Web应用程序的WEB-INF中。也许我需要配置其他设置。

任何帮助或任何方向将不胜感激。我已经学习了很多东西,但已经完成了很长一段时间,我已经解决了这个问题了一个星期。

由于

2 个答案:

答案 0 :(得分:1)

Look at the timeline. It starts at 19:49:23.766 in the Tomcat log with this message:

A valid shutdown command was received via the shutdown port. Stopping the Server instance.

Exit code 143 is a result of that shutdown and doesn't indicate anything.

The question you need answered is: Who send that shutdown command, and why?


On a side note: The earlier messages indicates that Tomcat lost connection to the database, and that you didn't configure a validation query. You should always configure that, since database connections in the connection pool will go stale, and that needs to be detected.


Theory: Do you have some monitoring service running that tests your application being up? Does that monitoring detect a timed-out database connection, classify that as a hung webapp and auto-restart Tomcat?

答案 1 :(得分:0)

While I don't think I am able to see to the core of the problem you have with your overall setup given the small excerpt of your log files, one thing strikes the eye. In the Tomcat log, there is the line

A valid shutdown command was received via the shutdown port. Stopping the server instance.

This explains why the server was restarted. Someone (some external process, a malicious attacker, script, or whatever. Could be anything depending on the setup of your server) sent a shutdown command to Tomcat's shutdown port (8005 by default) which made the Tomcat shut down.

Refer to OWASP's recommendations for securing a Tomcat server instance for fixing this possible security whole.

Regarding the ostensible Hibernate problems you have, I don't get enough information from your logs to make a useful statement. But you can leave the MySQL jar in Tomcat/lib, since this is not the root cause of your problem.