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 <ska-skaware_at_skarnet.org> 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
>
Received on Mon Apr 07 2025 - 15:42:24 CEST