Hello,
I'm writing a service for dirvish, and I realized that if I'm following
current guix service routes, I might not be able to run all the
operations I need to. It seems that the current route for Guix is to
have your service write out a config that more or less becomes part of
the environment for starting / stopping a daemon via Shepherd. But what
if that's not all you need to do?
Aside from just "running as a daemon", plenty of (especially
applications which manage state) will need to have other commands that
are unlikely to be run from shepherd. For example:
- Initializing a data store. For example, in dirvish I need to run
a command to initialize a "vault" where I will be storing my data.
- Manually invoking a garbage collection utility.
- Manually invoking an integrity check utility.
- Possibly some side effect involving querying the network.
- Running schema migrations.
All sorts of things! Most of them (all?) involve state or side effects,
but plenty of our most important services will be "state overlords" of
some type.
So it seems to me that one of two things will be needed... either:
- Expose the configuration file directly, possibly by putting in
`${profile}/etc/foo'
- Expose "wrapped" utilities. For example, instead of invoking
"dirvish" directly, I might invoke a wrapped dirvish.
What are our thoughts on how to deal with this? This is going to be
very important when moving towards GuixSD as a platform for server
deployment.
- Chris
PS: Note that for either of the above suggested methods, this will be
extra tricky when we have users running multiple services of the same
application. For example, we might have users running multiple
Wordpress installs or mail daemons or MediaGoblin instances on the same
machine, and I'm not really sure how you'd find which thing you're
looking for there (but I guess you have the same problem with which
identifier would be used in shepherd start/stop anyway).
