s6-rc: Managing small changes to the active services database

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sat, 31 Dec 2016 16:08:26 -0300

Hello,

Consider a fully s6-rc-managed machine. Such a machine would have an
'active' services database (the compiled database linked from s6-rc's
live state directory), and some place where service definitions would
be stored in source format. The active services DB would have been
initially created by running s6-rc-compile on all or part of these
definitions. I don't know what everyone else does, but the source
directory I give to s6-rc-compile is usually a temporary directory
with symbolic links to definitions stored somewhere else (in a sort of
services repository), that I delete afterwards.

After initial creation, with the possible exception of bundle
definitions, I imagine the active DB would be mostly static, and
expect changes to be generally small, like e.g. adding a couple of
services when there is a newly installed software package. Changes are
performed by running s6-rc-update on a new compiled DB, but
s6-rc-compile currently requires the full set of services in source
format to create one. So how would one manage this? Should one really
keep the source directories supplied to s6-rc-compile instead of
throwing them away, so they can be reused? Or construct a temporary
source directory from the services list returned by running s6-rc-db
on the live state directory, and then make the changes? Or...?

Also, depending on what method is used, there is the chance of missing
changes made in-place after the initial s6-rc-init invocation, like
using s6-rc-bundle on the live state directory to modify bundle
definitions (s6-rc-db's 'contents' subcommand could catch these), or
modifying longruns' env/ and data/ directories through the symlinks in
the scan directory (s6-rc-db cannot catch these).

Thoughts?
G.
Received on Sat Dec 31 2016 - 19:08:26 UTC