systemd service: restart less agressively but still quicker #13502
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.
If a service fails to start because it's not properly configured (e.g. directly after installation) the existing settings make the daemons restart in a loop. Each start logs several lines to the journal which quickly results in older but probably still relevant logs of other serives being rotated out.
Dropping RestartSec makes systemd use the default of 100ms. So a restart happens quicker. With dropping StartLimitInterval=0 systemd applies some ratelimiting and (by default) only starts the service 5 times per 10s.
Replacing Restart=on-failure by Restart=on-abnormal makes systemd not restart the service if the daemon process exits with a non-zero exit code. It's still restarted when the process exits by a signal (other than SIGHUP, SIGINT, SIGTERM or SIGPIPE).
Debian-Bug: https://bugs.debian.org/1055529
Short description
I'm well aware that these settings are very much depending on personal preferences. But IMHO this is another hint that pdns should stick to system defaults and let the administrator fine tune the settings if needed. The motivation to change these settings came from installing the Debian package which in my case resulted in an annoying restart loop. See the linked Debian bug report. The Debian maintainer asked me to forward this issue upstream; here it is.
Checklist
I have: