pid file creation as non-root

[muuki88]

I just upgrade a project from 0.7.0-M1 to 0.7.0-M3, which means the default appUser is now normalizedName.

First of all I had to chown -R myapp:myapp /usr/share/myapp
I tried to start the app with sudo service myapp start which fails with error

Exception in thread "main" java.io.FileNotFoundException: 
/var/run/myapp.pid (Permission denied)

Possible solution

I looked inside the directory and found that every non-root pid file was inside a folder which is owned by the user. So creating /var/run/myapp as the "pid-folder" seems a already used solution.

[jsuereth]

huh, so who was creating the pid file? It was there previously?

[muuki88]

Actually I have no idea. I just stumbled on this right now and will have a closer look hopefully this week.

[aparkinson]

Strange, I upgraded to 0.7.0-M3 on Friday and haven't seen anything similar.

@muuki88 Are you using Upstart or SystemV?

[kardapoltsev]

@muuki88 Are you using play project?

[muuki88]

• play 2.2.0
• Upstart

I'm hoping this is migration problem or the way I start the app with sudo service maybe sudo -u myapp service myapp will do the trick?

[kardapoltsev]

No, play server trying to create pid file from started application and you specify pidfile.path point to file that doesn't writeable for your appUser. I think that pid file should be created by start up system, systemV or upstart instead of application itself.

val pidFile = Option(System.getProperty("pidfile.path")).map(new File(_)).getOrElse(new File(applicationPath.getAbsolutePath, "RUNNING_PID"))

[aparkinson]

@kardapoltsev is correct about Play generating the pidfile.

It is worth noting Upstart does away with the need for a PID file, it's only the SystemV script that needs it.

[muuki88]

Nice! Thanks for the research. So in fact we have a problem, when every side has too much intelligence

Application	Startup System	Works
Creates PID	No PID	x
No PID	Creates PID	?
Creates PID	Creates PID	?
No PID	No PID	?

[aparkinson]

If both the application and the startup system create PID's they might not be in the same location and then you can have problems recovering from a crash.

Is it worth making SystemV the default startup system and consider sensible defaults for just that scenario?

We then can leave Upstart requiring a little extra configuration by the user.

[muuki88]

I think Upstart is fine as a default. The error occurs because I changed the default behaviour. In my case a pidDirectory would make sense, because the application manages the pid generation.

[muuki88]

This is closed with #176 For play look at the Production Configuration page.

Add src/templates/etc-default file with this line

-Dpidfile.path=/var/run/${{app_name}}/play.pid

[gbougeard]

I don't understand what to do .
which src/templates/etc-default are you talking about (in Play context)?

[kardapoltsev]

If you using play application you should go to /etc/default/$app_name after installation and uncomment line

# -Dpidfile.path=/var/run/${{app_name}}/play.pid

[gbougeard]

the goal of native packaging is to NOT modify files after installation, isn't it?

obviously we can imagine to use puppet do deploy packages and modify config files after installation but the ideal would be to be well configured just with package installation.
So, is it possible to configure it in the play application to have a configured right package?
Is it also possible to configure Xmx for the deployed app?

[kardapoltsev]

Alternatively you could provide your own template for /etc/default as suggested above.

[muuki88]

So, is it possible to configure it in the play application to have a configured right package?
Is it also possible to configure Xmx for the deployed app?

This is exactly what the etc-default is made for. Take a look at the documentation and/or at some examples.

[gbougeard]

thx a lot! sorry for noob questions :D

I succeed in what i wanted to do thanks to your answers.

2014-05-22 10:49 GMT+02:00 Muki [email protected]:

So, is it possible to configure it in the play application to have a
configured right package?
Is it also possible to configure Xmx for the deployed app?

This is exactly what the etc-default is made for. Take a look at the
documentationhttp://www.scala-sbt.org/sbt-native-packager/GettingStartedServers/AddingConfiguration.htmland/or at some
examples https://github.com/muuki88/sbt-native-packager-examples.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/164#issuecomment-43862925
.

[muuki88]

There are no noob questions, only bad documentation ;)

[shijinkui]

simple question: where is the pid when using JavaAppPackaging?

[muuki88]

Simple answer: nowhere. PIDs are only generated when you use the server archetype.

The JavaAppPackaging type online provides start scripts.

[shijinkui]

@muuki88 i don't think pid is only needed by server archetype.
if JavaAppPackaging provide a stop script, that will be perfact.

[He-Pin]

I have to generate the pid myself at application runtime for the JavaAppPackaging.
as we always run application as nohub ./application &
I think a RUNNINGPID and a stop script would be handy too.

[muuki88]

I think this is out of scope for the JavaAppPackaging archetype. If you start your application manually you with nohub you will have to deal with it yourself. This what the playframework does.

I recommend using the server archetype as you get all these facilities for free. You can start/stop your application with a simple sudo service my-app start. If your system uses Systemd then you have very sophisticated control.

if JavaAppPackaging provide a stop script, that will be perfact.

this is exactly what the system-loader infrastructure of your linux system are there for.

[He-Pin]

@muuki88 thank you,I know that with the server archetype would be good,and the problem currently is that ,we need restart the server and then redeploy it sometime,so we just go straight with the JavaAppPackaging.
the problem is that when we run multiply app on the same box,and them always kill it via killall java,and then miskill some others .so I think the server archetype would be great there.

I have only one question.with the server archetype,is it easily that I upgrade the app?or override it?
thanks.,and for the pid fancy,does that was provided by the underly system or by the sbt-native-packager.

Once I confirm this ,I will try to convert our current script to the server archetype.

[shijinkui]

@hepin1989 +1

@muuki88 thanks. Indeed we need JavaAppPackaging providing pid and stopping script.
sbt-native-packager cannot force user to user server archetype.

[muuki88]

@hepin1989

is it easily that I upgrade the app

Yes. You just replace JavaAppPackaging with JavaServerAppPackaging. Done. Depending on your operating system you may need to tweak the system loader. See the documentation for more details.

E.g.

import com.typesafe.sbt.packager.archetypes.ServerLoader.{SystemV, Upstart, Systemd}
// for Debian, Ubuntu
serverLoading in Debian := Systemd // if you have Ubuntu 15.04 for example
// for RHEL, CentOS, Fedora
serverLoading in Rpm := Systemd // if you want Fedora to use Systemd instead of SystemV

@shijinkui

cannot force user to user server archetype

No, but the server archetype is exactly the solution to your problem. The start script is intended to be executed by a application system that manages these applications, e.g.

• SystemV
• Upstart
• Systemd

If you don't install on the package level, then the JavaAppPackaging type is sufficient enough when you use for example a docker container. Or you write your own

• Aurora start script
• Amazon AWS script
• ...

SBT Native Packager will never provide facilities to manage applications on your system, because we support such a variety of systems that it's hard enough to make things work with existing things. I highly recommend you to use onboard facilities for application life-cycle management (systemd, systemv, upstart).

[He-Pin]

@muuki88 thanks,I means is it easily for me to upgrade a app only via dpkg -install newVersion.deb?.

[muuki88]

Yes :)

[shijinkui]

In our company, docker is not recommended. Most of applications are managed by tomcat or other web container. For breaking away from tomcat, i choose scala, netty and Play.
But the deploy mode, i need manage app for myself and don't care any os type. That's why need pid and stop script. we have ourselves' package and deploy management system.

anyway, u cant't give someone only one way or bind someone to other framework tightly.

so, pid and stop script maybe choosed by use optionally.
💯

[muuki88]

I think there are a few points you are confusing. I try to explain things in more detail so you get a better feeling of what I mean when I say "sbt native packager will not provide an application lifecycle management".

JavaAppPackaging and JavaServerAppPackaging

JavaServerAppPackaging is not something different as JavaAppPackaging. In Fact JavaServerAppPackging depends on JavaAppPackaging and adds the following functionality for deb and rpm packagaes

• default folders
  -- /var/run/<appname> for PIDs
  -- /var/log//<appname> for logs
• daemon user and group
• maintainer scripts that
  -- register your app as a service with the configured SystemLoader (SystemV, Upstart, Systemd)
  -- start app
  -- stop app before unstinall / upgrade

You see that this features have only one purpose: managing application lifecycle on a server.

anyway, u cant't give someone only one way or bind someone to other framework tightly.

With JavaAppPackaging you can choose any binding, e.g. some implemented AWS Beanstalk Bindings in #632. You have a start script and build around your application lifecycle management.

JavaServerAppPackaging gives you three standard lifecycle managements for free: SystemV, Upstart and Systemd. These are three bindings, not one. And you have to do nothing in order to use them.

i need manage app for myself and don't care any os type

You can still package zip, tar etc. files. The JavaServerAppPackaging won't altering. Currently native-packager only supports deb and rpm within the server archetype.

Implement a stop script

Furthermore, what does it mean to implement a stop script and manage your application yourself.

1. Find a OS independent place to put your PIDs. That place must be readable and writeable
2. Make sure the application isn't running yet
3. Check the status of the app

all with bash/bat foo which heavily relies on your OS you are running on. You can not "not care" about your OS you are running your stuff on. Providing a stop script means implementing an application lifecycle management. It is hard enough to keep SystemV, Systemd and Upstart running on all major linux distributions. Implementing your own is a) not a good idea b) not part of packaging plugin.

so, pid and stop script maybe choosed by use optionally

If you use the JavaAppPackaging you can implement your own application lifecycle if you think that's a good idea. SBT Native Packager will only provide hooks into existing systems. As an example we could implement a binding for Aurora to start applications easily on an Aurora cluster, but we would never implement anything like Aurora. That is out of scope.

I hope you get the point that packaging and running are two separate concerns. Native-packager gives you a package that any system should be able to execute. Managing your application state is (and should be) done by other systems. SBT native packager provides at most bindings ( in form of configuration files, scripts and sys calls ) to these systems as we do for SystemV, Systemd and Upstart.

[shijinkui]

@muuki88 Thank for your detail reply with patience.
Stop script is not sbt-native-packager's responsibility. Maybe sbt-native-packager focus on native more.
Let's step back, can sbt-native-packager write the pid to the defined location file?

[muuki88]

@shijinkui you're welcome :) This is really an important topic as this about the scope of sbt-native-packager.

can sbt-native-packager write the pid to the defined location file

You can use bashScriptExtraDefines setting to do what ever you want in your start script. At this point you can apply your bash foo. See docs for details. On the Cheatsheet page you may find some interesting points as well.

Still. I highly recommend against a custom application life cycle management. killall java is not a good way to manage applications. Learn more about your Server OS and use the facilities provided.

[He-Pin]

@shijinkui you could use scala at taobao?I don't think so .
And if you are using the Play,then Play comes with pid already.

[muuki88]

@hepin1989 Yeah, play creates it's own PID which makes things a little tricky sometimes. If you use play you are already using the server archetype. Play enables it by default. However you have to configure the PID location

[shijinkui]

@hepin1989 My last scala project use play framework with the pid. Current working have no need to use it again. Play also have to much dependencies, and depend on special netty version. I work in aliyun.

@muuki88 i tried that tricky way. Thanks. If plugin can generate pid by default, it will be more clean for developer. 👍
That' all.

[He-Pin]

@shijinkui hem,you could using scala:).would you mind join our akka group(257534530) and play group(128259394) at qq?

I think you could package the stop script to the package just as Play does.

[muuki88]

@shijinkui you need a PID if need to manage the application lifecycle (start-stop-status-restart). See my last comment above how to add these stuff in bashScriptExtraDefines. What I forgot: You also need to add a folder in the linuxPackageMappings where the executing user has write access. Therefore you need to know which user will execute your application.

I will close the discussion here as

1. SBT Native Packager will not provide any application lifecycle management
2. The solutions to build a homegrown application lifecycle management are in this and my last comment