bug#60657: Rethinking how service extensions work

[Bruno Victal <mirai@makinata.eu>]

Hi all,

The current situation with services in Guix is that service extensions do not care about dependencies.
This can result in cryptic errors as seen in [1].

In [1], the issue arises from using activation-service-type to create files/directories for services
when these should be either (1) shepherd one-shot services or moved into the 'start' procedure of the service.
'activation-service-type' should only be used for doing things "listed on its label", that is, performing
actions at boot-time or after a system reconfigure.

But both solutions (1) and (2) are still not enough as the directories themselves might not yet
be available and the services must be aware of this fact and wait for them to be ready. One example
would be a network dependent mount or a simple service that mounts a volume such as:

--8<---------------cut here---------------start------------->8---
(simple-service 'mount-overlayfs shepherd-root-service-type
                (list (shepherd-service (requirement '(foo-mount))
                                        (provision '(overlayfs-foo))
                                        (documentation "Mount OverlayFS.")
                                        (one-shot? #t)
                                        (start (let ((util-linux (@ (gnu packages linux) util-linux)))
                                                 #~(lambda _
                                                     (system* #$(file-append util-linux "/bin/mount")
                                                              "-t" "overlay"
                                                              "-o" (string-append "noatime,nodev,noexec,ro,"
                                                                                  "lowerdir="
                                                                                  (string-join '("/srv/foo/overlays/top-layer"
                                                                                                 "/srv/foo/overlays/layer2"
                                                                                                 "/srv/foo/overlays/layer1"
                                                                                                 "/media/foo-base") ":"))
                                                              "none" "/media/foo" )))))))
--8<---------------cut here---------------end--------------->8---

This example also means that it's untenable to just look into the file-systems field entries and attempt
to intelligently discover which paths are required for the services and add them as dependencies (another hole to this idea
is that overlayfs and some fuse filesystems can mount over the same path).

I've proposed in [2] for the service procedure to accept optional arguments, these could be of interest in solving this problem.
Another place we should look at is how systemd manages its service dependencies, with the 'Wants', 'After', 'Before', 'RequiresMountsFor', etc. [3]
directives. These could potentially be implemented and used alongside [2].

Such changes might also imply that a UI change in herd is required to handle the structured information or to avoid cluttering it with too
much "noise".


[1]: https://issues.guix.gnu.org/57589#12
[2]: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00292.html
[3]: https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BUnit%5D%20Section%20Options