GNU bug report logs -
#60657
Rethinking how service extensions work
Previous Next
Full log
Message #14 received at 60657 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo’,
On 2023-02-25 17:46, Ludovic Courtès wrote:
> Bruno Victal <mirai <at> 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
This bug report was last modified 2 years and 75 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.