bug#60657: Rethinking how service extensions work

[Bruno Victal]

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