Init script changing ownership of /var/run on my system causing other services to fail writting pid file

[f-ld]

I had a look to other issues and the problem seems new.

Here is what I have in my setup:

• an application deployed in /opt/myapp with the jar in /opt/myapp/myapp-X.Y.Z-R.jar
• an init.d script defined like this (created to read the /etc/default/myapp file):

#!/bin/bash

NAME=myapp
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
MYAPP_JAR=`find /opt/myapp/lib/ -name \\*\\.jar`
${MYAPP_JAR} $@

• the jar belongs to myappuser
• the /etc/default/myapp files contains a few APP specific env variables and also sets JAVA_HOME, MODE=service, server host, port and context path (not relevant for this ticket).

Now this is what happens
In that case and when reading the init script inside the jar (identified as being this one: https://github.com/spring-projects/spring-boot/blob/9e8beb7323215f5de0aaa778699fe70717604f39/spring-boot-tools/spring-boot-loader-tools/src/main/resources/org/springframework/boot/loader/tools/launch.script)

• L28: JARFILE is not set so not setting jarFile
• L29: APP_NAME is not defined so not setting identity
• L33: since jarFile is still emtpy, we set it to /opt/myapp/myapp-X.Y.Z-R.jar
• L34: JAR file exists but is not a symbolic link, so we do not enter the loop and do not set init_script
• L53: PID_FOLDER nor pidFolder are previously defined, so PID_FOLER is set to /var/run
• L55: /var/run exists and is executable so nothing changed
• L63: identity is still empty so we enter the block
• L64: init_script is an empty string, so we jump to the else block
• L67: we set identity to myapp-X.Y.Z-R_optmyapplib
• L111: init_script and APP_NAME are still empty strings not equal to identity, so we do no enter the block
• L114: we set pid_file to /var/run/myapp-X.Y.Z-R_optmyapplib.pid
• L150: when trying to start the app, we do a chown myappuser /var/run

And this is where it gets broken: other services then cannot write their PID inside /var/run because owner has changed (from root to myappuser) and dir mode is 755 so user from root group cannot write there

There is an easy workaround: set the APP_NAME variable and then it will all be fixed for us. But since others may have the same issue, I think something has to be done (maybe ensure that we do not change permissions if PID_FOLDER ends up being /var/run or maybe simply remove the if on L111)

[philwebb]

@wilkinsona can you quickly review this change to make sure it's sensible?

[wilkinsona]

Ideally, if we're creating a directory in /var/run then we should change its ownership so that it's owned by the user that will run the app. Even more ideally, we wouldn't sometimes create /var/run/app.pid and other times create /var/run/app/app.pid. However, changing this might be a breaking change for some so I think we should probably fix that in 1.5 at the earliest. I've opened #6924.

In the meantime, I think we should chown the pid folder when we've created a sub-folder using the identity.