-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Root should handle its shutdown state #110677
Comments
afharo
added
bug
Fixes for quality problems that affect the customer experience
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Team:Operations
Team label for Operations Team
labels
Aug 31, 2021
Pinging @elastic/kibana-operations (Team:Operations) |
Pinging @elastic/kibana-core (Team:Core) |
afharo
changed the title
Root should handle its state
Root should handle its shutdown state
Aug 31, 2021
This was referenced Sep 1, 2021
Fixed by #161869, closing |
pgayvallet
added a commit
that referenced
this issue
Nov 2, 2023
delanni
pushed a commit
to delanni/kibana
that referenced
this issue
Nov 6, 2023
…70309) ## Summary Fix elastic#109684 Most of the work was already done in elastic#110677, this PR just remove a deprecated call to `toPromise()`, a better error message and a unit test to assert the behavior.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Root class calls
this.shutdown(e)
when any of the lifecycle steps breaks. This allows us to gracefully shutdown Kibana when any of those steps throw an error.The problem is that it's also called externally when a
SIGTERM
orSIGINT
signal are emitted. So there's the possibility that we receive that signal while Kibana is still processing requests from any of its lifecycle steps.This is causing that a signal that should make Kibana exit 0, might end up logging
FATAL Error
while still exiting0
if any of the lifecycle steps throws when a condition is not met (i.e.: ES connection is closed prematurely or never properly opened yet).IMO, we should handle the state (and potentially cancel the promises) on the first
shutdown
call. This can be done either in theRoot
class or thebootstrap.ts
logicThe text was updated successfully, but these errors were encountered: