The policies decided; now the supervisor obeys. When a service is reaped, it consults the policy and, if a restart is warranted, spawns the service afresh and counts the attempt. Today the pieces connect - a crashed on-failure service comes back to life.
On reap, consult the policy and restart the service if warranted, counting the restart.
This is the moment every policy lesson was building toward: the supervisor stops
merely deciding and starts doing. When a Running service is reaped, it lands
in Exited as before, and then the supervisor immediately asks ShouldRestart. If
the answer is yes, it spawns the command again through the runtime - a brand-new
handle, back to Starting - and increments a RestartCount so it can tell how many
times this service has come back.
That restart count is not bookkeeping for its own sake: it is the seed of crash-loop protection. A service that keeps crashing will keep restarting here, forever, with no pause between attempts - a tight, punishing loop. Right now the restart is immediate, which is fine for one comeback but dangerous for a persistent crash. The next chapter fixes both problems: it spaces restarts out with exponential backoff, and it gives up entirely once a service has restarted too many times too fast.
// after classifying a Running exit into Exited inside Reap:if ShouldRestart(svc.Policy, code, svc.ManuallyStopped) {svc.RestartCount++svc.Handle = s.rt.Start(svc.Command) // Exited -> Startingsvc.State = Starting}