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

问题描述

编辑：有一个相关问题是在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运行--restart = always -d --name playappcontainer./opt/bin/playapp 。

当我 $ service docker stop&&服务码头重启
然后 $ docker attach playcontainer 控制台告诉我：

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).

---

那么为什么包含RUNNING_PID的文件不是当docker守护程序停止时，删除，重新启动并重新启动以前运行的容器？

---

当我 $ docker检查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，并在
a宽限期后，SIGKILL。

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

从 $ docker停止的Docker参考

要杀死运行播放服务器，就够了发送一个SIGTERM到
进程以正常关闭应用程序。

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

从停止播放应用程序的播放框架文档

推荐答案

根据答案和我在这个问题上的进一步的工作，我整理了一个工作的解决方法。如果我启动容器如下，他们将在（un）预期的停止/重新启动后启动。冲突的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.

这篇关于重新启动播放应用程序Docker容器导致“此应用程序已在运行” - RUNNING_PID不会被删除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！