nspcc-dev / nspcc-dev/neofs-node
Graceful shutdown if metrics/pprof/control service is not available
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 38
- Forks
- 51
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 38
Description
Is your feature request related to a problem? Please describe.
If some bad happens in http.Serve we just die instantly: here, here and here. These services are kinda the most important for us (they allows us understanding if the other services work in general and making decisions based on statistic information) but not that important to kill application on any error like os.Exit(1).
Describe the solution you'd like
Find out a better way to handle these errors e.g. canceling app context and waiting for other services to shutdown.
Describe alternatives you've considered
Do nothing, it works almost all the time ok.
Additional context
After https://github.com/nspcc-dev/neofs-node/issues/2585, https://github.com/nspcc-dev/neofs-node/issues/2428 and similar things, canceling context may become not the best way to do it: metrics will be the first thing to run and if they die, other services may not be inited yet (and initialization sometimes take its time and no Init takes context.Context), so no shutdown will be performed until all the Init is done.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with cmd/neofs-node/metrics.go, cmd/neofs-node/pprof.go, and cmd/neofs-node/control.go at the http.Serve calls, then trace the application initialization and shutdown flow. Determine how failures in these auxiliary services should be handled when other services are still initializing; done means such failures no longer immediately terminate the application and shutdown behavior is consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100