[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Guix shepherd user services
Guix shepherd user services
Sun, 10 Feb 2019 16:02:05 +0100
mu4e 1.0; emacs 26.1
I've been thinking about shepherd user services.
We just had a discussion on the topic:
and an interesting patch was sent a while ago:
Jelle first introduced me to this idea during the Guix days and it took
me a while to understand why it's pure awesomeness. In short: just like
we can fully configure an operating-system in Guile and we don't have to
touch /etc manually, we could do the same with our user profile. At
last, done with .bashrc / .profile to start user daemons, cron jobs,
whatever synchronization script you use...
It would also make it possible to fully _initialize_ a user profile (just like
we initialize the operating-system) with the desired files. For instance, a
service could synchronize git repositories (e.g. your dotfiles), deploy it,
synchronize your emails, generate the mlocate cache, snapshot some btrfs drives,
you name it.
As a result, on a Guix install it would be possible to run
guix service --install -f my-services.scm
let the magic happen, relog(?) et enjoy a 100% pre-configured user
profile. How cool is that?
Benefits over traditional dotfiles or cron jobs:
- No more need for .xinitrc, .local/bin, etc.
- Declarative and uniformly programmable in Guile.
- Every service is uniformly controllable (start, restart, stop, status, etc.).
It's not so convenient to do that with a daemon that was started from
- Drags non-propagated inputs automatically, no need to polute the user profile
(e.g. with redshift, xcape, etc.)
- Pre-configured services to choose from, as provided by Guix (unlike mcron).
My thoughts regarding the implementation design:
- Services can be enabled, disabled, started, restarted, stopped, listed,
they can show details and documentation, they can run pre-defined actions.
They are semantically very different from packages (in fact they often use
packages, but not always). I don't think it would be good to mix and match
services and packages in a command like `guix package --list-installer`. So I
suggest we keep them separate.
- The user must be able to build and install services. We could have the
following behaviour then:
`guix service --build redshift` would produce a
`guix service --install redshift` would install it to
`guix service --remove redshift` would remove it from the above location.
`guix service --upgrade=redshift` would rebuilt the service (and maybe
redshift) and install the new version.
- How do we write custom services? Well, just like we write custom packages and
custom operating-system, in a channel or in GUIX_PACKAGE_PATH (which name
becomes less and less meaningful).
- How do we update services (e.g. the redshift service when the redshift package
just got updated)? My understanding is that services are citizens similar to
operating system declarations: they depend on the current Guix version and the
user-defined definitions (e.g. channels).
Then `guix pull && guix service --upgrade` will do.
- How do we start the user shepherd on login and load the service configuration?
We need to be cautious to support foreign distributions. On GuixSD, we could
arrange /etc/profile to run
shepherd --config ~/.guix-profile/service-manifest.scm
on login. On foreign distributions, users can add the above command to
~/.profile, or ~/.bashrc, etc.
- If the package manifest and the service manifest are separate, it follows that
we now have 2 parameters to "reproducibly" define a user profile. I think
that's fine and it allows for composition (mix and match service manifests and
- Currently I think it's not possible to just define shepherd services without
enabling them. Thus it's not possible to have a list of available services
just like we have a list of packages. While this might be OK for the system
(but is it?), I think it would be nice if, as a user, we could do a
guix service --list-available
and pick services from there. This is somewhat a separate issue but
it would be nice to solve it. I don't know enough about the shepherd
internals to go into the details here.
- Should Guix drive the services with a `guix service` subcommand or should we
leave it to `herd` run by the user? Since we use `herd` for system services,
I think it's more consistent to stick to `herd`.
I'd like to work on it with anyone interesting on the topic. I know
some people I've worked on it before, so feel free to share your
Description: PGP signature
- Guix shepherd user services,
Pierre Neidhardt <=