I made java application that's supposed to be executed as daemon. I am using an Amazon Linux AMI, which uses SysVinit and I already have an init script for my daemon, I am just a bit confused on where to place the files.

At first I was going to place my jar file at the /usr/bin folder, since I guess there's where regular programs go, but I my program uses 2 libraries, so as a matter of fact I have 1 jar file and and lib file with 2 libraries inside it.

I am concerned about placing the jar file at /usr/bin and then the libraries at /usr/lib since the jar and the lib folder are supposed to be on the same folder, besides, I feel this can make a mess with my system if those libraries are updated by another program in the future, breaking some functionality by mistake, not to mention things starting to get cumbersome with so many different files spread everywhere.

But since I like to comply with standards, I don't want to go and just create a random folder for my program and drop all I need inside of it.

Is it there a correct way to deploy systems like this on Linux? How`s the best way to deploy a java daemon that needs some libraries too?


1 Answer 1


Placing JAR file in /usr/bin directory is totally not a good idea. There are bunch of reasons for that by the first and the most important is security. More or less, applications should be isolated. Placing binaries and unknown and potentially unsecure files side by side with system wide software makes attack surface wider than it's needed. Creating separate directory has bunch of benefits: logical separation, security and many others. I highly recommend a book I have read recently, Continuous Delivery.

My recommendations:

  • create separate user and group for this Java application with its own home directory, let's call it app-user,
  • deploy all artifacts there,
  • create systemd unit or sysv unit that runs this Java application as the app-user and loads your libraries from app-user home directory.
  • 1
    I do agree that using the home of a user, or using /usr/local/app_name are the best approaches; I would advise expanding slightly the answer explaining why it is not a good idea to use /usr/bin. +1 Commented May 4, 2017 at 9:59
  • Yes I would like to know why it's not a good idea and what's the benefit from /usr/local/app_name
    – mFeinstein
    Commented May 4, 2017 at 14:09
  • Added small description and one book reference. Commented May 4, 2017 at 15:55
  • Interesting, and I agree with everything...I just don't understand then why linux has all those default folders then, made for all these different things, like compiling binaries, placing config files, placing source to be compiled and etc like in here en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard are you implying that the linux filesystem hierarchy is flawed and should be avoided?
    – mFeinstein
    Commented May 4, 2017 at 21:33
  • Basically, I am not complaining about the FS hierarchy at all, here. This might be a different topic how this hierarchy and it's usage is different in misc. Linux distributions. The clue of my mind is... - Do not trust your application. It is potentially unsecure. I would say even - it is unsecure and has bugs for 99,9999%. It should be isolated. You can treat your application as a third party software and you want to have it as much separately as it is possible. Commented May 4, 2017 at 23:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .