systemd services and service states

What it means

A service unit is a definition of management behavior, not the running program itself. Its configuration describes what should happen; runtime state describes what the manager currently reports. Neither, by itself, proves that the application can do useful work.

This example isolates one transition: an unexpected exit of the service’s main process leads to a restart decision. It does not represent the service’s entire lifecycle. In particular, an unrequested successful exit is not the same event as an administrator intentionally stopping the service.

Try it

Simulation: begin with Restart policy = on-failure, Prior exit = failure and Start-rate limit reached? = no. Change only Start-rate limit reached? to yes, then inspect the result and its explanation. Use Compare with baseline to show the current outcome alongside the documented baseline. No command is sent to systemd.

The baseline result is “Restart attempt permitted.” Its explanation is “This exit matches the selected restart condition.” The initial example remains readable without JavaScript; changing inputs and comparing results require JavaScript.

Keep Restart policy = on-failure and Prior exit = failure unchanged while changing Start-rate limit reached? from no to yes.

Reset restores Restart policy = on-failure, Prior exit = failure and Start-rate limit reached? = no. It clears input errors and the baseline comparison. It preserves your independent choices to open or close FAQ answers and About this model.

How it works

The model separates the decision into two stages. First, the policy determines whether this exit calls for a restart:

Second, if the policy requests a restart, the model checks the supplied rate-limit state. A reached limit blocks the attempt; an unreached limit permits it within this exercise.

This order matters to the explanation. With Restart policy = no, Prior exit = failure and Start-rate limit reached? = yes, the result is still “No automatic restart attempt,” but the reason is that the policy does not request one. The limiter does not change that decision: there is no policy-requested attempt for it to block.

The result deliberately says “Restart attempt permitted,” not “service healthy.” Permission to attempt a start does not establish that a replacement process starts successfully, becomes ready or serves user requests correctly. Those outcomes need their own evidence.

Worked example

This is a synthetic baseline, not a captured production event.

The failure matches on-failure, so the first stage requests a restart. The supplied rate-limit state is no, so the second stage does not block it. The computed result is “Restart attempt permitted,” with the explanation “This exit matches the selected restart condition.” No process is launched by this calculation.

What changes when the condition changes

Change only Start-rate limit reached? to yes. Keep Restart policy = on-failure and Prior exit = failure.

The result becomes “No automatic restart attempt.” The explanation is “Start-rate limiting blocks restart attempts in this exercise.” The failure still matches the policy, but the next condition now blocks the attempt. This overturns the assumption that a matching Restart= setting guarantees a restart.

In practice

On a host that uses systemd, begin with authorized, read-only inspection of one named service unit. Identify the unit and service type, inspect its installed configuration and applicable overrides, and review its current state and recent unit-scoped journal covering the stop. Use documentation appropriate to the installed systemd version.

Look for evidence that distinguishes a requested stop from an unexpected exit, establishes the exit classification, and indicates whether start-rate limiting was involved. The expected useful observation is a supported explanation of that particular event—not merely a policy setting that could explain some failures.

STOP if the unit identity, permissions, event classification or relevant evidence is uncertain. Preserve the available logs and leave the cause unknown rather than testing a guess with repeated starts. Keep this inspection read-only: do not edit the unit, clear limiting state or start and stop the service to make it match the example.

This page is not a configuration-change procedure. Any real change needs a separately scoped, authorized plan with the prior configuration saved, checks of both manager state and application behavior, and a rollback method whose result can also be verified.

Limits and unknowns

The visible result applies only to an unrequested main-process exit in a non-oneshot service with default success/failure classification. Manual stops, status overrides, other conditions and readiness are not modeled. The scene does not observe a real service or establish that a replacement process actually started.

The supported selections produce a decision within this model; they cannot discover missing host evidence. If you do not know the real exit classification or rate-limit state, the real-machine conclusion remains unknown—do not turn uncertainty into a guessed yes or no. If an input is invalid, no calculated outcome applies until it is corrected or Reset is used.

What to carry forward

Treat a restart decision as evidence about an allowed attempt, not proof of recovery. For an unexpected stop, first establish the exit classification and applicable configuration; then check whether another condition blocked the attempt. Verify application behavior separately before calling the service recovered.