重新启动 Play 应用程序 Docker 容器会导致 '此应用程序已经在运行'- RUNNING_PID 未被删除 [英] Restarting Play application Docker container results in 'This application is already running' - RUNNING_PID is not deleted

查看:111
本文介绍了重新启动 Play 应用程序 Docker 容器会导致 '此应用程序已经在运行'- RUNNING_PID 未被删除的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有一个相关问题正在在 Github 上讨论,但在另一个部署模式(Typesafe Activator UI 而不是 Docker).

There is a related issue being discussed on Github but in another mode of deployment (Typesafe Activator UI and not Docker).

我试图模拟系统重启,以验证 Docker 重启策略,该策略声明能够以正确的顺序重新运行容器.

I was trying to simulate a system reboot in order to verify the Docker restart policy which declares to be able to re-run containers in the correct order.

我有一个用 Java 编写的 Play 框架应用程序.

I have a Play framework application written in Java.

Dockerfile 如下所示:

The Dockerfile looks like this:

FROM ubuntu:14.04
#
#  [Java8, ...]
#
RUN chmod +x /opt/bin/playapp
CMD ["/bin/bash"]

我使用 $ docker run --restart=always -d --name playappcontainer "./opt/bin/playapp" 启动它.

当我 $ service docker stop &&服务docker重启然后 $ docker attach playappcontainer 控制台告诉我:

When I $ service docker stop && service docker restart and then $ docker attach playappcontainer the console tells me:

Play server process ID is 7
This application is already running (Or delete /opt/RUNNING_PID file)

当我按照 Play 文档的建议 使用-Dpidfile.path=/var/run/play.pid将文件的位置更改为/var/run/play.pid.

Same result when I follow the recommendation of the Play documentation to change the location of the file to /var/run/play.pid with -Dpidfile.path=/var/run/play.pid.

Play server process ID is 7
This application is already running (Or delete /var/run/play.pid file).

<小时>

那么:当 docker 守护进程停止、重新启动并重新启动之前运行的容器时,为什么包含 RUNNING_PID 的文件没有被删除?

<小时>

当我 $ docker inspect playappcontainer 时,它告诉我:

"State": {
    "ExitCode": 255,
    "FinishedAt": "2015-02-05T17:52:39.150013995Z",
    "Paused": false,
    "Pid": 0,
    "Restarting": true,
    "Running": true,
    "StartedAt": "2015-02-05T17:52:38.479446993Z"
},

虽然:

容器内的主进程会收到SIGTERM,之后一个宽限期,SIGKILL.

The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.

来自 $ docker stop 上的 Docker 参考

要杀死正在运行的 Play 服务器,发送一个 SIGTERM 到正确关闭应用程序的过程.

To kill a running Play server, it is enough to send a SIGTERM to the process to properly shutdown the application.

来自 关于停止 Play 应用程序的 Play 框架文档

推荐答案

我根据答案和我在这个问题上的进一步工作整理出了一个可行的解决方法.如果我按如下方式启动容器,它们将在(意外)停止/重启后启动.冲突的 RUNNING_PID 文件不会阻止容器重新启动.

I sorted out a working workaround based on the answers and my further work on this question. If I start the containers as follows, they'll be up after an (un)expected stop/restart. The conflicting RUNNING_PID file won't prevent the container from restarting.

$ sudo docker run --restart=on-failure:5 -d \
--name container my_/container:latest \
sh -c "rm -f /var/run/play.pid && ./opt/bin/start \
-Dpidfile.path=/var/run/play.pid"

它的作用是删除包含进程 ID 的文件,该文件每次在运行二进制文件之前都使用一个选项放置在特定位置.

What it does is deleting the file containing the process ID which is put at a specific place using an option everytime before running the binary.

这篇关于重新启动 Play 应用程序 Docker 容器会导致 &amp;#39;此应用程序已经在运行&amp;#39;- RUNNING_PID 未被删除的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆