Hi,
2017-02-22 7:18 GMT-03:00 Guillaume Perréal:
>
> Tweaking my services, I have wondered where to put their configuration.
>
> For longruns, one could either put the in the data/ and env/ subdirectories,
> or in a /etc subdirectory. The former allows to easily have different
> instances of the same services but the files might be harder to locate, and
> requires to update the s6-rc database to change the configuration. The
> latter allows to use a well-known location and to update the configuration
> without updating the s6-rc database.
For longruns env/ and data/ work; the current working directory for
longruns is their s6 service directory (generated by s6-rc-compile),
so env/ and data/ can be referred to in 'run' and 'finish' scripts
using relative paths, a style that aligns with daemontools-like
supervision suites usage -s6 is the underlying mechanism after all-.
And doing it that way *does* allow dynamic changes without recompiling
the services database. What happens though is that if the 'boot time'
database (i.e. the one used in the s6-rc-init invocation) is not
recompiled, those changes don't survive a machine reboot. The usage of
env/ and data/ was touched upon in an a supervision ML thread:
<
http://www.mail-archive.com/supervision%40list.skarnet.org/msg01549.html>
Quoting Laurent: "I think env/ and data/ should be used for
configuration that is mostly static, i.e. that can wait until a
database recompilation to be applied. For configuration that needs to
be applied immediately, it is best if services store their config in a
directory that is fully independent from the service directory
location, and access it via absolute paths". But, to be honest, I
still like that one is able to make such in-place changes, and like
s6-rc-bundle for the same reason.
> For oneshots, as one cannot use neither env/nor database. There is no much
> solutions.
Yup, oneshots need independent directories referenced by absolute
path; the current working directory for their 'up' and 'down' scripts
is s6rc-onsehot-runner's service directory in s6-rc's current
implementation (i.e. with s6-sudoc + s6-sudod as the underlying
mechanism).
My personal preference for anything (s6-rc-specific) that needs to be
referenced by absolute path in 'run', 'finish', 'up' or 'down' would
be /etc/s6-rc/misc/$SERVICE_NAME, with $SERVICE_NAME matching the name
in s6-rc's service database (i.e. as shown by 's6-rc-db list all').
And /etc/s6-rc/misc/$SOMETHING_REPRESENTATIVE for things that do not
'belong' to a single service, but might be shared among many (like
general enough auxiliary scripts) -implying that
$SOMETHING_REPRESENTATIVE is then unavailable as a service name, of
course-.
> The same question goes for helper scripts (for example, the "event handler"
> of udhcpc, responsible for applying the configuration). I'm torn between
> putting them in s6-rc/scripts/the-service-that-uses-them, a "scripts"
> subdirectory in their configuration, or something like
> {/lib,/usr/share}/the-service-that-uses-them.
My choice of 'misc' in /etc/s6-rc/misc also means that I think placing
scripts there is OK too :), but if I had to choose an alternative, it
would be something under /lib with 's6-rc' in the name. On my machine
it would be something like /lib/skarnet/s6-rc/$SERVICE_NAME, because I
put anything 'libexec-like' under /lib/skarnet for both s6 and s6-rc
(and s6-linux-init-maker-like stage2, stage2_finish and stage3 scripts
would be in /lib/skarnet/s6-init). I wouldn't choose anything under
/usr, because on a machine with s6-rc as part of its init system I
consider anything that might be invoked by a service 'essential'
enough to be on the rootfs.
G.
Received on Wed Feb 22 2017 - 20:18:21 UTC