guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Shepherd news + planned feature removal


From: Adam Faiz
Subject: Shepherd news + planned feature removal
Date: Fri, 24 Feb 2023 00:35:20 +0000

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’.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]