Hi Ludo’, On 2023-02-25 17:46, Ludovic Courtès wrote: > Bruno Victal <mi...@makinata.eu> skribis: >> 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. > > Right. > > As we once discussed on IRC, the conclusion to me is that some of the > code currently implemented as activation snippets should rather be > implemented either as part of the ‘start’ method of the corresponding > Shepherd service, or as a one-shot Shepherd service that the main > service would depend on.
I think moving them into the ‘start’ method is the best course of action. I'm considering the following changes: * Adding (gnu build activation) to %default-imported-modules + %default-modules in (gnu services shepherd). I expect that mkdir-p/perms is going to be used frequently enough, using the number of activation-service extensions in use as a rough estimate. * Refactor the activation extensions into the ‘start’ method, where it makes sense to do so. There's one issue I'm somewhat concerned about, consider the following snippet: --8<---------------cut here---------------start------------->8--- (define log-directory "/var/log") (define username "notroot") (start #~(lambda _ (mkdir-p/perms #$log-directory (getpw #$username) #o750) ...)) --8<---------------cut here---------------end--------------->8--- This is somewhat pitfall prone since you most likely don't want to chown /var/log to a non-root user. I'm unsure what's the best course to take here, would a simple file-exist? check before mkdir-p/perms be sufficient? In either case, with or without refactoring this issue is already present (but in activation-service extensions) so it's no worse than the status quo. >> (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" ))))))) > > Note that this should prolly be declared as a ‘file-system’ rather than > as a custom service. That way, it would get a “standard” Shepherd > service. > > There are cases where we add explicit dependencies on > ‘file-system-/media/foo’ or similar. <file-system> has a ‘dependencies’ > field specifically for this purpose (info "(guix) File Systems"). > > Would that work for you? Unfortunately OverlayFS is filtered out from fstab by Guix (reported #60246) and the dependencies field IMO is too restrictive, there should be a (sane) way to pass shepherd service symbols too. (for cases where a file system depends on 'networking or depends on a particular interface e.g. NFS mount that uses a IPv6 link-local address) Cheers, Bruno