Notify systemd when Elasticsearch is ready #44673
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Today our systemd service defaults to a service type of simple. This means that systemd assumes Elasticsearch is ready as soon as the ExecStart (bin/elasticsearch) process is forked off. This means that the service appears ready long before it actually is, so before it is ready to receive requests. It also means that services that want to depend on Elasticsearch being ready to start can not as there is not a reliable mechanism to determine this. This commit changes the service type to notify. This requires that Elasticsearch sends a notification message via libsystemd sd_notify method. This commit does that by using JNA to invoke this native method. Additionally, we use this integration to also notify systemd when we are stopping.
jasontedor
added
>enhancement
:Delivery/Packaging
|
Pinging @elastic/es-core-infra |
alpar-t
reviewed
Jul 22, 2019
alpar-t
reviewed
Jul 22, 2019
|
|
||
| static { | ||
| AccessController.doPrivileged((PrivilegedAction<Object>) () -> { | ||
| Native.register(Libsystemd.class, "libsystemd.so.0"); |
There was a problem hiding this comment.
Won't this fail with the packaged distributions on OS-es that don't support systemd, or does everything in our support matrix support it ?
There was a problem hiding this comment.
We don’t try to load the native library if the environment variable ES_SD_NOTIFY is not set to “true” and in this PR we do that only in the systemd service integration (see the unit file).
I considered the existing packaging tests sufficient, since if this integration is broken due to the service type being set to I’ll look more carefully if there is deeper testing we can do but I considered the existing packaging tests sufficient. |
jasontedor
commented
Jul 23, 2019
modules/systemd/src/main/java/org/elasticsearch/systemd/SystemdPlugin.java
Outdated
Show resolved
Hide resolved
|
@elasticmachine update branch |
rjernst
approved these changes
Jul 23, 2019
| @@ -24,6 +24,10 @@ | |||
| //// SecurityManager impl: | |||
| //// Must have all permissions to properly perform access checks | |||
|
|
|||
| grant codeBase "${codebase.jna}" { | |||
There was a problem hiding this comment.
Can this go below the "Very speciall jar permissions" comment please, with the rest of the jar specific grants? (yes the SM here is a jar specific grant, but the comment above is specific to secure SM)
jasontedor
added a commit
that referenced
this pull request
Jul 24, 2019
Today our systemd service defaults to a service type of simple. This means that systemd assumes Elasticsearch is ready as soon as the ExecStart (bin/elasticsearch) process is forked off. This means that the service appears ready long before it actually is, so before it is ready to receive requests. It also means that services that want to depend on Elasticsearch being ready to start can not as there is not a reliable mechanism to determine this. This commit changes the service type to notify. This requires that Elasticsearch sends a notification message via libsystemd sd_notify method. This commit does that by using JNA to invoke this native method. Additionally, we use this integration to also notify systemd when we are stopping.
polyfractal
pushed a commit
to polyfractal/elasticsearch
that referenced
this pull request
Jul 29, 2019
Today our systemd service defaults to a service type of simple. This means that systemd assumes Elasticsearch is ready as soon as the ExecStart (bin/elasticsearch) process is forked off. This means that the service appears ready long before it actually is, so before it is ready to receive requests. It also means that services that want to depend on Elasticsearch being ready to start can not as there is not a reliable mechanism to determine this. This commit changes the service type to notify. This requires that Elasticsearch sends a notification message via libsystemd sd_notify method. This commit does that by using JNA to invoke this native method. Additionally, we use this integration to also notify systemd when we are stopping.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today our systemd service defaults to a service type of simple. This means that systemd assumes Elasticsearch is ready as soon as the ExecStart (bin/elasticsearch) process is forked off. This means that the service appears ready long before it actually is, so before it is ready to receive requests. It also means that services that want to depend on Elasticsearch being ready to start can not as there is not a reliable mechanism to determine this. This commit changes the service type to notify. This requires that Elasticsearch sends a notification message via libsystemd sd_notify method. This commit does that by using JNA to invoke this native method. Additionally, we use this integration to also notify systemd when we are stopping.