Read ES_HOME, APP_NAME and APP_LONG_NAME from JVM config file

[mihneasim]

This patch modifies the init.d service script to read existing values for elasticsearch home path and app name (service name) from elasticsearch.conf

Like this, the wrapper is location independent on Linux. It is no longer required to be placed in bin of elasticsearch!
I can't tell the same about Windows (I don't know), that's why I moved that requirement in the Readme to the Windows section.

Thank you!

[kimchy]

hey, thanks for the work!. The problem with those type of changes is that the files are coming from the Java Service Wrapper project, and if we upgrade then we somehow need to keep the 2 in sync.

We now have a deb and rpm packages, which we recommend to use compared to the Java Service wrapper.

[mihneasim]

Hello Shay,

I can see your reasoning, but I don't fully get how it applies to these changes. Isn't the file I changed already a specific fork for elasticsearch?
E.g., I edited lines like:

# determine elasticsearch home
ES_HOME=`dirname "$SCRIPT"`/../..

What we need here at the EEA is to have two deployments in custom paths of elasticsearch, on the same machine, in separate "sandboxes".

[kimchy]

Yea, it doesn't, I am trying though to understand what you would use the service wrapper compared to the deb/rpm package (unless you are running on windows)? Trying to get users to move away from it.

[mihneasim]

We have two deployments in custom paths, on the same machine, which need to be managed independently:

• one for production
• one for development, where we can play with future version before upgrading the production

We can't do this with system managed packages.