Thanks for quick clarification! I think I'll hard-code oneshot scripts: it’s about the same amount of complexity to use a generic script that reads data from somewhere and manage its data, as is to just create one from a template with all concrete data in it. (like init-eth3 in the example).
A couple of questions: * Is there already a way to find the exit status of oneshots? * In the examples, init-lan is oneshot that reads env vars from somewhere, but I could not figure out what injects those vars into its environment: importas -i ETH0_IP4 ETH0_IP4 importas -i ETH1_IP4 ETH1_IP4 importas -i ETH2_IP4 ETH2_IP4 If these are passed down from s6-svscan environment, how did they get injected there? — Damir > On 7 Apr 2025, at 14:38, Laurent Bercot <[email protected]> wrote: > >> s6-envdir: fatal: unable to envdir env: No such file or directory >> s6-rc: warning: unable to start service local-ip: command exited 111 >> >> It appears that s6-rc doesn’t like the relative path to `env` directory in >> the `up` script? > > Yes. > The env/ and data/ subdirectories are only valid for longruns. When you > write oneshots, you cannot add random data to the source definition > directory - it won't get compiled into the database. > > This is on purpose. The intended way of using oneshots is for you to > decide your own place to store data, and use absolute paths in your > up/down scripts. > Try storing your environment in /etc/s6-rc/env/local-ip for instance. > > I realize this is confusing (and could probably be better documented, > I will try to make it clearer); but it is a design decision in s6-rc to > enforce as little policy as possible. > > I am (finally!) working on s6-frontend, the higher level interface; > when it's complete it will provide you with a place to store global data. > So you won't be burdened with the hardships of choice, and free will, for > much longer. > > -- > Laurent >
