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.


Reply via email to