-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Be more conservative with service restarts #210
Comments
could you please provide some extra informationfor example Specific Fields:You've mentioned Metadata, LogTargets, Dependencies, and service actions as fields that shouldn't trigger a restart. Are there any other fields you think should be included in this list? Real-world Issues:Can you share some examples where the current restarts have been a problem? Fallback:Would you still want a manual restart option? Config:Should be there a setting to toggle this feature ? |
My opinion is basically: we should restart a service if and only if we make a change that requires a new Linux process. If we can just modify the existing process - let's do that, no need to restart. If we're just changing metadata or configuration which is external to the actual process, then we can just make that change without restarting the process.
I don't have a "real-world" example, but this caused surprising behaviour while I was writing tests for log forwarding. Service restarts trigger changes down the line (e.g. in the log manager). I can imagine it would be an issue if we're using Pebble to run a service where availability is important - the current behaviour causes unnecessary downtime.
We already have the
No, because you can manually restart a service if you really want. Note that because this is a breaking change to Pebble behaviour, we'd probably need approval from top brass before implementing this. |
For reference, here is the original thread where we discussed this. |
To avoid service disruption, Pebble should restart services only when absolutely required. Currently, any change to the service definition will trigger a service restart. However, IMO there are a few fields which shouldn't require restarting the services:
Summary
,Description
,Override
LogTargets
, as log forwarding is managed externally from the service by the log manager.The text was updated successfully, but these errors were encountered: