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.