Closed lonix1 closed 1 year ago
Controlling a service from within itself works and is supported, but is bad practice and generally a sign that you are abusing the pattern and need to redesign something.
Here you are using a supervised service to perform work that must only be done once. This is a misuse of s6; oneshot scripts are not meant to be supervised, and s6 is not the right tool to run your script. If you need to run it in an init sequence, for instance, the right tool for you to use would be s6-rc.
GitHub is not the place where we host s6 discussions. For more support, please join the supervision mailing-list. Thanks.
In my case the docker image is outside of my control, so the service "terminating itself" is the only simple/reasonable option. I'm glad it's supported.
I will look into s6-rc. Thanks for the advice!
If it's a Docker image then they're likely using s6-overlay, which internally uses s6-rc already. :-)
I don't think so, but I will tell them to look into it. Thanks for the tip.
Ah, indeed they're not using s6-overlay. Using pure s6 is entirely fine here - it just doesn't have the same purpose, and in this case there should be a different place in the container's run scripts where you can run your oneshot.
I use a docker image which uses s6. I added my own custom
/etc/s6/custom/run
s6 service script, which performs some work (only once), and then must not be restarted.I thought if that script simply creates a
/etc/s6/custom/down
file, the service will not be restarted - but it is.So instead the script performs its work, then does this:
$ s6-svc -D /etc/s6/custom
. That seems to work.But I'm calling s6 from inside an s6 service. I wonder whether that is a supported scenario, or whether I am asking for trouble?