Ludovic Courtès <ludo@gnu.org> writes:

> Today I added support for “one-shot” services in the Shepherd:
>
>   https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804
>
> One-shot services start, perform a short action, and are immediately
> marked as “stopped.”  (systemd has something similar:
> <https://www.freedesktop.org/software/systemd/man/systemd.service.html>.)
>
> The use case is initialization or cleanup actions like the ‘user-homes’
> service.  So far ‘user-homes’ is a regular service whose ‘start’ method
> always fails; as a result, we always see this message:
>
>   Service user-homes could not be started.
>
> From there on, we’ll be able to mark this service as one-shot (patch
> below), and thus shepherd will notice that it successfully started (or
> not) and yet mark it as stopped, which was always the intent.
>
> There are other cases where this could be useful.  For instance, we
> could turn service activation snippets into one-shot services.
>
> Since this augments the Shepherd API, I plan to release it as 0.6.0
> in time for Guix 1.0.  It contains other rather minor changes compared
> to 0.5.0.

This seems like a good change.

At first I was a little confused about why we would ever want to use a
one-shot shepherd service instead of an activation snippet, but after
reviewing the account-shepherd-service, I think I understand.  It seems
that we make it a one-shot shepherd service instead of an activation
snippet so that we can take advantage of shepherd's service dependency
management.  In the case of account-shepherd-service, it looks like we
made it a shepherd service to ensure that it would run after
'file-systems' is up.  This makes sense, since it could be a little
awkward to try to ensure proper execution order by extending the
activation service, and even if we did that, it would duplicate the
dependency management logic that shepherd gives us already.

So yeah, it makes sense to me.

-- 
Chris