3.8 Service Removal
When a definition disappears from Machine\System\Services\, peinit
learns of it through the ordinary change-notification path.
What happens next depends
on whether anything is running.
3.8.1 Not running #
An entry in Inactive, Failed, Completed, Skipped, Abandoned or Backoff is discarded immediately. There is no process to consider.
Backoff belongs in this list rather than the next one, which is not obvious: a service between restart attempts looks like it has something pending. It does not. It has no process, and once the definition is gone there is nothing left to restart it from, so there is neither an instance to supervise nor a restart to wait for.
3.8.2 Running #
An entry in Active, Starting, Reloading or Stopping is not killed. The running process is a job, and a job's lifecycle is independent of the definition that produced it — removing a definition stops future management, it does not terminate work in progress.
peinit marks the entry definition-removed and keeps the cached
definition, solely to go on supervising the instance it already has.
When that instance
exits it is not restarted — RestartPolicy is moot, because there is
nothing left to restart from — and peinit then discards the entry.
A definition-removed entry never has dependents. A read in which one
service Requires another the read does not define is refused whole,
with MissingHardDependency — so a removal that would leave a dangling
hard dependency does not land at all, and the administrator has to
remove the dependents first.
While an entry is definition-removed:
stopis accepted, so an administrator can drain it cleanly, using the cachedStopTimeout;start,restartandreloadare rejected withUNKNOWN_SERVICE— there is no definition to work from;statusreports the current runtime state withdefinition_removedset, so the draining instance is visible rather than silent.
definition-removed is a flag on the existing runtime state, not a
state of its own. The state machine (§6.1) and the command × state
matrix (§10.3) are unchanged by it.
A restart already in its stop phase is a case of its own. The stop
phase still drains the existing instance; the start phase does not
begin, because there is nothing to start from. When the instance exits,
the operation is aborted with the reason
definition_removed_during_restart_stop_leg and the entry takes the
ordinary removal discard.
This is the window a package upgrade opens —
remove the definition, then restart the service.
Once the instance exits or is stopped, the entry — including anything in its fd store (§10.6) — is discarded. A crash counts: the exit is routed to Failed rather than into a restart, because there is no policy left to apply. The fd store goes with it, which a crash would otherwise preserve for the restart that is not going to happen.