Shepherd news + planned feature removal

[Adam Faiz <adam.faiz@disroot.org>]

> Hello Guix!
> 
> I recently pushed an updated and rebased variant of
> ‘wip-service-monitor’ in the Shepherd, previously discussed here:
> 
>   https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html
> 
> I’m going to merge it real soon if there are no objections, with the
> goal of using it as the basis for 0.10.x and hopefully soonish 1.0.x.
> 
> The main news are:
> 
>   • Services can now be in one of 4 states: stopped, starting, started,
>     and stopping.  (Previously it was just started/stopped.)
> 
>   • ‘herd status SERVICE’ reports those new states.
> 
>   • ‘start’ waits if the service was already starting; ‘stop’ waits if
>     the service was already being stopped.
> 
>   • Services are now started in parallel, to the extent possible.
> 
> Internally, the big change is that, in addition to a “service registry”
> actor (a fiber and associated channel where it receives requests), each
> service has an associated actor (likewise, a fiber) that handles
> service-specific operations such as ‘start’ and ‘stop’.  I find it
> aesthetically pleasing and fun to work with; incidentally, it should
> sound familiar to the goblins among us.  :-)
> 
> There’s a couple of shepherd features that I’d like to remove:
> “persistency” (sic), and the “unknown” service.  These things were added
> in the early days of dmd ca. 2003 but they’re totally untested, likely
> broken, and probably useless.  If you have objections, now’s the time to
> let it be known.

I'm ok with current service state persistency being removed, since users can 
always modify a copy of the shepherd configuration file and tell the shepherd to 
load that instead, which achieves the same thing.

The 'unknown service fallback seems like a really cool feature, but if there 
isn't really any use for it, then I guess it should be removed. It can always be 
added back in if someone has a usecase for it.

I just have 1 question: Why is there a need for `herd status` to display whether 
a service is in a starting or stopping state?

 From the perspective of the shepherd, a service that is starting isn't running 
yet, and a service that is stopping isn't stopped yet.
The "starting" and "stopping" states are just an implementation detail to handle 
the shepherd being asynchronous. It's the running and stopped states that a user 
wants to know about a service.

> 
> Feedback welcome!
> 
> Ludo’.
>