-
-
Notifications
You must be signed in to change notification settings - Fork 599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init script - improvements needed #130
Comments
For (1) and (2), please check with authors of these changes (git log) and ideally submit a separate issue/patch for these. |
Please also see #98 and other issues related to init script (https://github.com/elasticsearch/cookbook-elasticsearch/search?o=desc&q=init&s=updated&source=cc&type=Issues) |
I'm having problems using the init script on Ubuntu 12.04. It seems the elasticsearch-env.sh method of initiating start-stop-daemon doesn't work for me. I have to manually put those values in the /etc/init/elasticsearch init script and make sure they're exported before elasticsearch is willing to start. |
Please use git log/blame to check with the authors of respective scripts, let's reopen this if we can simulate this in Vagrant. @jhtran Interesting -- I'm frequently running the tests on Vagrant with |
The start script generated by this cookbook doesn't work for me with Chef, Vagrant and Precise64. If I run sudo /etc/init.d/elasticsearch start I don't see anything in the Elasticsearch logs. This init.d script works for me: I can start Elasticsearch manually with:
|
(1) on the debian platform family, why do you use start-stop-daemon to start yet when stopping the process you use kill $(cat $PIDFILE)? start-stop-daemon can be used to stop the proc as well.
(2) so many assumptions made in stop and restart that make the logic brittle:
(a) the last thing a process does before terminating is erase its pid file - can't be guaranteed to be true so why is the stop() checking for the presence of the pid file as a mechanism for determining the process has stopped? instead, we should be using something more universally true like kill -0 returning an error when the no longer exists.
(b) the ps | grep | grep -e logic is brittle. when a process is shutting down and releasing memory, on some systems ps will show the process as [java] with no arguments. there are so many variations to this that attempting to use ps + grep is never going to work across a large number of systems
(3) on debian platforms, why not use status_of_proc since it's complementary to start-stop-daemon?
The text was updated successfully, but these errors were encountered: