Restarting Play application Docker container results in 'This application is already running' - RUNNING_PID is not deleted

Question

Edit: There is a related issue being discussed on Github but in another mode of deployment (Typesafe Activator UI and not 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.

I have a Play framework application written in Java.

The Dockerfile looks like this:

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

I start it using $ docker run --restart=always -d --name playappcontainer "./opt/bin/playapp".

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)

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

---

So: Why is the file containing the RUNNING_PID not deleted when the docker daemon stops, gets restartet and restarts previously run containers?

---

When I $ docker inspect playappcontainer, it tells me:

"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"
},

Although:

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

from the Docker reference on $ docker stop

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

from the Play Framework documentation on stopping a Play application

Answer 1

I've just dockerized a Play! application and was also running into this issue - restarting the host caused the Play! application to fail to start in its container because RUNNING_PID had not been deleted.

It occurred to me that as the Play! application is the only process within its container, always has the same PID, and is taken care of by Docker, the RUNNING_PID file is (to the best of my knowledge) not actually needed.

As such I overrode pidfile.path to /dev/null by placing

javaOptions in Universal ++= Seq(
  "-Dpidfile.path=/dev/null"
)

in my project's build.sbt. And it works - I can reboot the host (and container) and my Play! application starts up fine.

The appeal for me of this approach is it does not require changing the way the image itself is produced by sbt-native-packager, just the way the application runs within it.

This works with sbt-native-packager 1.0.0-RC2 and higher (because that release includes https://github.com/sbt/sbt-native-packager/pull/510).