pub struct RestartPolicy { /* private fields */ }Expand description
The restart-on-failure policy, and the bound on how fast it may retry.
05-infrastructure.md item 3: “set a restart-on-failure policy with bounded
delay”. Both halves matter and they are different requirements. A service
that does not come back after a crash defeats Journey 5; a service that comes
back instantly, forever, turns one bad configuration into a fork bomb against
GitHub’s rate limit. So the delay has a floor as well as a ceiling, and the
floor is what does not restart-loop faster than that bound is measured
against.
Implementations§
Source§impl RestartPolicy
impl RestartPolicy
Sourcepub const MIN_DELAY: Duration
pub const MIN_DELAY: Duration
The shortest delay this will accept.
One second is not a tuning preference. Below it, launchd’s own throttle
and systemd’s start-limit logic both take over and the configured number
stops being the number in force, so a policy under this floor would be a
value service status reported and the platform ignored.
Sourcepub const MAX_DELAY: Duration
pub const MAX_DELAY: Duration
The longest delay this will accept. Past five minutes an operator watching a restart would reasonably conclude the service is simply gone.
Sourcepub const DEFAULT_DELAY: Duration
pub const DEFAULT_DELAY: Duration
What service install uses when nothing is said.
Sourcepub const DEFAULT_RESET_AFTER: Duration
pub const DEFAULT_RESET_AFTER: Duration
How long the service must stay up before its failure count is forgotten.
Sourcepub fn new(delay: Duration, reset_after: Duration) -> Result<Self, ServiceError>
pub fn new(delay: Duration, reset_after: Duration) -> Result<Self, ServiceError>
§Errors
ServiceError::RestartDelay when delay is outside
RestartPolicy::MIN_DELAY..=RestartPolicy::MAX_DELAY, or when
reset_after is not longer than delay — a reset window shorter than
the delay can never elapse between two restarts, so the failure count
would reset on every attempt and no start-limit could ever trip.
Sourcepub const fn delay(&self) -> Duration
pub const fn delay(&self) -> Duration
How long the service manager waits before restarting a failed service.
Sourcepub const fn reset_after(&self) -> Duration
pub const fn reset_after(&self) -> Duration
How long the service must run before its failure count resets.
Sourcepub const fn effective_delay(&self, kind: DefinitionKind) -> Duration
pub const fn effective_delay(&self, kind: DefinitionKind) -> Duration
The delay a given manager can actually express.
Three of the four take seconds and enforce exactly what they are given.
Windows Task Scheduler does not: RestartOnFailure/Interval is
expressed in whole minutes with a one-minute floor, and it rejects the
registration outright rather than rounding — PT15S comes back as
“The task XML contains a value which is incorrectly formatted or out of
range”, which is how this was found.
So the interval is rounded up, never down, and never below one
minute. The direction is the point: the requirement is that the service
“does not restart-loop faster than that bound”, and a delay longer
than the configured one still satisfies it, while a shorter one would
not. service status reports the difference as a note so that an
operator reading 15s in the record and 60s from the manager is told
why rather than left to wonder.
Trait Implementations§
Source§impl Clone for RestartPolicy
impl Clone for RestartPolicy
Source§fn clone(&self) -> RestartPolicy
fn clone(&self) -> RestartPolicy
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more