Re: Configuration and scripts location

From: Laurent Bercot <>
Date: Wed, 22 Feb 2017 21:14:08 +0000

>Tweaking my services, I have wondered where to put their configuration.

  Choose a place for configuration directories that is entirely
from your s6/s6-rc installation, typically in /etc. Put your
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
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
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
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

  Anything that doesn't need to be in a service directory should be
of it; anything that isn't related to s6/s6-rc should avoid living in
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.

Received on Wed Feb 22 2017 - 21:14:08 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC