-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Die with dignity #19272
Die with dignity #19272
Conversation
+1 |
Today when a thread encounters a fatal unrecoverable error that threatens the stability of the JVM, Elasticsearch marches on. This includes out of memory errors, stack overflow errors and other errors that leave the JVM in a questionable state. Instead, the Elasticsearch JVM should die when these errors are encountered. This commit causes this to be the case.
LGTM, I like it |
We might want to document the exit codes somewhere too |
@tlrx I think that's a good idea, but I'm unsure of a good place to document it. Do you or @clintongormley have any ideas? |
FYI we documented something similar for plugins: https://www.elastic.co/guide/en/elasticsearch/plugins/current/_other_command_line_parameters.html |
@jasontedor not perfect, but perhaps a section under Setup? |
This commit adds docs for the Elasticsearch shutdown process, distinguishing between a clean shutdown and an unclean halt due to fatal error.
If you're running Elasticsearch directly, you can stop Elasticsearch by sending control-C if you're | ||
running Elasticsearch in the console, or by sending `SIGTERM` to the Elasticsearch process on a | ||
POSIX system. You can obtain the PID to send the signal to via various tools (e.g., `ps` or `jps`) | ||
or by specifying a location to write a PID file to on startup (`-p <path>`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When ran directly the pid is shown in the logs/stdout too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I should be more clear. I think we can rephrase like:
Elasticsearch indicates the PID in logs or standard ouput during startup:
[INFO ][node ] [Araña] version[2.3.3], pid[6674], build[218bdf1/2016-05-17T15:40:04Z]
You can also obtain...
or something like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed 4550140. Is that more like what you had in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4550140 is good, thanks!
This commit adds a note to the Elasticsearch stopping docs that indicates that the Elasticsearch PID is also available from the Elasticsearch startup logs.
@tlrx @clintongormley I pushed docs in 74c1708; could you take a look? |
LGTM |
Sorry I'm late to this. You can also get the PID from the node info API:
|
@clintongormley Yes, and the cat nodes API too. The concern I have there is that that will list all the nodes in the cluster when only the local node is needed and that leads to more effort on the end-user? I'm happy to add these though if you think otherwise. 😄 |
Today when a thread encounters a fatal unrecoverable error that
threatens the stability of the JVM, Elasticsearch marches on. This
includes out of memory errors, stack overflow errors and other errors
that leave the JVM in a questionable state. Instead, the Elasticsearch
JVM should die when these errors are encountered. This commit causes
this to be the case.
Relates #19231