11

Problem

My project builds just fine using sbt docker:publish or sbt docker:publishLocal, but when I go to run the image, it fails with the following stack trace: 

eleanor@demo-machine:~/workbench/opendar/opendar$ docker run eholley/opendar:1.0-SNAPSHOT
Oops, cannot start the server.
java.nio.file.AccessDeniedException: /opt/docker/RUNNING_PID
        at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
        at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
        at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
        at java.nio.file.Files.newOutputStream(Files.java:216)
        at play.core.server.ProdServerStart$.createPidFile(ProdServerStart.scala:136)
        at play.core.server.ProdServerStart$.start(ProdServerStart.scala:43)
        at play.core.server.ProdServerStart$.main(ProdServerStart.scala:25)
        at play.core.server.ProdServerStart.main(ProdServerStart.scala)
eleanor@demo-machine:~/workbench/opendar/opendar$

To Reproduce

The image is public on DockerHub under eholley/opendar:1.0-SNAPSHOT. (In the run command, I have omitted a couple of environment variables, so the expected output should be that it fails on configuration based on the application.conf instead of the above error.)

If you want to try to build and package it yourself, you can clone https://0x00F3@bitbucket.org/0x00F3/opendar.git.

What I've tried

The issue isn't altogether dissimilar to this issue, so as a shot in the dark I tried adding this 

import com.typesafe.sbt.packager.docker.DockerChmodType
dockerChmodType := DockerChmodType.UserGroupWriteExecute

per the advice in the thread. It didn't appear to change anything.

Background

  • Ubuntu Version 18.04.2 LTS
  • Java version openjdk 1.8.0_191
  • sbt version 1.2.1
  • Scala version 2.12.6
  • sbt-native-packager version 1.3.21
  • Play Framework version 2.6.20
Eleanor Holley
  • 691
  • 1
  • 7
  • 27
  • 4
    Update: Working around this issue by setting `play.server.pidfile.path=/dev/null` in the application.conf, but I'm leaving the question open to a real answer. – Eleanor Holley May 16 '19 at 20:14
  • 3
    That actually is the real answer The playframework has for historic reasons its own PID file handling, which is unnecessary in container environments. – Muki Jun 05 '19 at 07:00

2 Answers2

12

I had to add both:

build.sbt

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

conf/application.conf

play.server.pidfile.path=/dev/null
James Ward
  • 29,283
  • 9
  • 49
  • 85
1

This problem is noted and has a few issues on various repositories on github https://github.com/lightbend/sbt-reactive-app/issues/177

You can either point the pid file to /dev/null like some otheres suggest or if you are using later versions of sbt native packager you can set the permissions for the docker user via the sbt setting

dockerChmodType := DockerChmodType.UserGroupWriteExecute

YisraelU
  • 352
  • 1
  • 8