service start on Centos produces ENOTTY error

[soenkeliebau]

I have tried to compile a small script from the play 2 framework as a rpm package using the sbt-native-packager. This produces a valid rpm, but on Centos the startup script in etc/init.d does not work, it seems to me, that the application tries to do something that requires a tty which nohup currently used in the startup template does not provide. I have asked about this on stackoverflow as well, further details can be seen there.

I managed to work around this by changing the start-call in the script in etc/init.d as follows:

RUN_OPTS=-Dpidfile.path=$PIDFILE
daemon --user $DAEMON_USER ${RUN_CMD} ${RUN_OPTS} &> logs/daemon.log

I've also removed the lines echoing the PID into the PIDFILE further down, which moves responsibility for the pidfile to the application, the script just uses it to kill the process when necessary.

This seems to work fine for me on Centos6.5. I have also changed the template for the script to reflect these changes, but was unable to successfully compile the packager for some scala reason I don't fully grasp, so couldn't test these changes.
I am happy to create a pull request if this is deemed a sensible change.

[kardapoltsev]

I've also removed the lines echoing the PID into the PIDFILE further down, which moves responsibility for the pidfile to the application, the script just uses it to kill the process when necessary.

Specially for play applications we have notes in etc-default-template

# For play applications you may set
# -Dpidfile.path=/var/run/${{app_name}}/play.pid

In this case 2 pid files will be created.

which moves responsibility for the pidfile to the application

That not a good idea I think because in this case all programmers should implement same functionality in their apps. Also, my application doesn't know anything about different systems and pid file locations.

Just let play application create another pid. See #164 for more details about this.

[muuki88]

We struggeled a lot with the daemon command as this leaves the responsibility to the app. It only worked in specific cases.

Can you give some more details on the error and your CentOS setup so we can reproduce the error.

Overriding the template can be done via configuration. Take a look at http://www.scala-sbt.org/sbt-native-packager/DetailedTopics/archetypes.html#overriding-templates

[muuki88]

Oh. I read your stackoverflow answer. Nice work @kardapoltsev