RPM directories not owned by user / group as expected

[jon-shanks]

I have built the RPM package using sbt-native-package 0.7.0-RC1 and when the application is built and the RPM is installed on centos 6.5, it fails to own the directory with the relevant user of the application %{NAME} as expected.

/usr/share/application is owned by root:root and its contents.

Play is then trying to place a RUNNING_PID inside this directory when it starts, as the %{NAME} user and is unable to do so due to perms.

I have tried changing the permissions on the directory using code found on a similar issue but it failed to work:

.settings(linuxPackageMappings += packageMapping(
          (target.value / "usr/share/application") -> "/usr/share/application"
          ) withUser "app" withGroup "app" withPerms "0755" withContents()
)

Not quite sure how to get the right user and group to own the directories it is creating, i can't see anything in the codebase that identifies in linuxPackageMappings and packageMappings that is identifying the user / group, but this is me just trying to understand the code so probably missing it.

[jon-shanks]

Is there a way not to specify a target but to declare just the end point with the right permissions and user recurisvely?

[kardapoltsev]

Please, take a look at #170 , #174 , #178 and #210 :)
And specially for play application you could add

-Dpidfile.path=/var/run/$app_name/play.pid
to /etc/default/$app_name

[muuki88]

First, try to use the newest RC (0.7.0-RC3).
The server app comes with a prefined pid directory, which is /var/run/<your-app>. This is owned by your daemonUser and group. Define this directory in your etc-template file.

https://github.com/muuki88/sbt-native-packager-examples
@kardapoltsev , we may provide some docs for play users?

[kardapoltsev]

Yes, I think we should add some notes about play pid file because it's not so obvious, but now I am very busy at work unfortunately...(

[jon-shanks]

great, thanks for the information.

I actually had already started using the pidfile.path to the application, after doing a bit of digging about. The issue is though, that the init script starts the application dropping in the pid, which then play sees (because i've passed it in) and decides not to start as the pidfile already exists.

Also, the /etc/default isn't something used by RPM's it uses /etc/sysconfig/<app_name> and generally expects some exported variables, which will be passed on to the script or used by the script i.e. JAVA_OPTS etc. So this is what is contained for the pidfile path to the play application.

Also i had issues with upgrades of the package, because there was a preuninstall and a postuninstall section for removing the user. But nothing for stopping the application in the preuninstall, so i've had to change it with my own:

rpm.preun="if [ \"$1\" = \"0\" ] ; then ; service %{name} stop > /dev/null 2>&1 ; chkconfig --del %{name} ; fi"

Otherwise, as it's nohup, it's effecitvely disowning the shell the application was started in, leaving the user logged in and hence, can't delete the user and fails.

It might be worth having a CREATE_PID variable that if true, will manage the PID and if false, won't bother and will leave it to the application to create it.

[jon-shanks]

Is it possible to place my own startup script in the templates directory and it use it or is it only using that for the etc-default template?

[muuki88]

No it should be possible to override the startscript there. Can you post it here or provide a pullrequest with the fixes?

[jon-shanks]

sure, so in the start-rpm-template

# Source function library.
. /etc/rc.d/init.d/functions

prog="${{app_name}}"

# Should the pidfile be handled by the startup script or by the application
CREATE_PID=${CREATE_PID:-"yes"}

(This defaults to yes unless specified elsewhere i.e. in the /etc/sysconfig/<app_name> configuration file.)

Then further down:

# Insert pid into pid file for CentOS killproc function
[ -d "/var/run/${{app_name}}" ] || install -d -o "$DAEMON_USER" -m750 "/var/run/${{app_name}}"

# Check if we want to create the PID bash substition is Bash 4 only, which is on most current OSes
#
if [ "${CREATE_PID,,}" == "yes"]
then
  echo $PID > ${PIDFILE}
fi
return $retval

This means in my application, i ship a /etc/sysconfig/<app_name> file and inside it i have

JAVA_OPTS="-Dpidfile.path=/var/run/\<app_name\>/running.pid"
#Set create pid
CREATE_PID="no"

export JAVA_OPTS CREATE_PID

So, the startup script won't manage the creation of the pid file but can still kill the process and start the process and get the legitimate play application pid as oppose the pid of the shell that spawned the play application

[muuki88]

Thanks a lot for sharing. I hope we'll be able to integrate this in some way.

[muuki88]

Has to be done after #348