>Tweaking my services, I have wondered where to put their configuration.
Choose a place for configuration directories that is entirely
independent
from your s6/s6-rc installation, typically in /etc. Put your
configuration
there and address it via absolute paths.
For oneshots, it's the only solution, because there's no notion of
"local data" with oneshots.
For longruns, you could also use data/ and env/ subdirectories, but I
generally recommend only putting a small amount of information in there,
preferrably volatile information (typically what you'd get from
instancing
or programmatically creating service directories any other way). The
reasons for it are:
- having all your config in /etc is clearer for most people - having to
look for the service directory to find config files is what put off a
lot
of people with daemontools. If you can't scatter *everything*, and you
most probably can't, then it's better to gather everything than to have
a
mixed bag of config locations.
- with s6-rc, live service directories are duplicated from the storage
copy, and they're likely stored in a tmpfs - which means every file in
the service directory is copied to RAM. This is expensive, and not
necessary for config files.
>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. Moreover, considering
>that the service scripts are moved around, use of absolute paths is
>required.
Anything that doesn't need to be in a service directory should be
outside
of it; anything that isn't related to s6/s6-rc should avoid living in
places
typically used by s6/s6-rc.
My udhcpc event handlers live in /etc/udhcpc for instance.
This is intentional: s6 and s6-rc enforce as little policy as possible,
and let you store your files wherever you want. This makes it easier for
an admin/distro to support several service managers.
--
Laurent
Received on Wed Feb 22 2017 - 21:14:08 UTC