Skip to content
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

systemd service: restart less agressively but still quicker #13502

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ukleinek
Copy link
Contributor

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:

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
@Habbie Habbie added the auth label Nov 16, 2023
@Habbie Habbie added this to the auth-4.9.0 milestone Nov 16, 2023
@coveralls
Copy link

coveralls commented Nov 16, 2023

Pull Request Test Coverage Report for Build 6892693968

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 21 unchanged lines in 4 files lost coverage.
  • Overall coverage decreased (-0.01%) to 57.402%

Files with Coverage Reduction New Missed Lines %
modules/gpgsqlbackend/gpgsqlbackend.cc 1 88.62%
pdns/packethandler.cc 3 72.71%
pdns/recursordist/test-syncres_cc2.cc 3 89.05%
modules/lmdbbackend/lmdbbackend.cc 14 72.24%
Totals Coverage Status
Change from base Build 6890076727: -0.01%
Covered Lines: 105523
Relevant Lines: 153204

💛 - Coveralls

@Habbie Habbie modified the milestones: auth-4.9.0, common-soon Jan 23, 2024
@omoerbeek
Copy link
Member

omoerbeek commented Jan 26, 2024

The reasoning appears solid, but this needs review by somebody knowing systemd (and that is not me).

@zeha
Copy link
Collaborator

zeha commented Jan 26, 2024

Seems like a bad time to make this change when systemd upstream seems to lean towards changing to a more "stay up" default configuration. Maybe wait for that to happen?
(Sorry don't have links at hand.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants