Marking a longrun service as up or down before boot
rauanmayemir opened this issue · comments
In v2, we could create a file like s6-touch /etc/services.d/myservice/down
to indicate that we don't want to start myservice
during boot.
In v3, creating a down is meaningless. I tried something like s6-touch /etc/s6-overlay/s6-rc.d/user/contents.d/myservice
, but it won't work either. (if I don't have myservice in user contents, it won't start altogether)
It seems like no matter what I do at /etc/cont-init.d
phase, user contents.d is getting picked up before that. What is the correct way to mark a longrun service as runnable or non-runnable?
If you don't want a service to be automatically started at boot time, don't add it to the user
bundle. It will still be present in the database, but it will be initially down.
@skarnet This is how I'm doing it now, but I want to dynamically decide whether I need to start it during cont-init
. s6-touch /etc/s6-overlay/s6-rc.d/user/contents.d/myservice
will not start the service at boot time. (e.g I run it in case certain env var is present)
Ah. Indeed, the s6-rc database, once built, is static, and you cannot change it in cont-init
. If you want to dynamically change the db, you'll need to do it in a S6_STAGE2_HOOK
script.
Alternatively, you can keep the longruns you want to control dynamically in /etc/services.d
and keep setting down
files, that has not changed.
Thanks, I rolled it back to /etc/services.d
so now everything is up. Naming it legacy was a sure way to cause FOMO. 😄
It's legacy in the sense that we're not going to expand on it or change the functionality in any way. But there are no plans to get rid of it.
I missed the part about S6_STAGE2_HOOK
the first time. Turns out, it was exactly what I needed.
I've migrated to v3 way and can now define dependencies. 🙌
after struggling (and failing) to get this working in v3 I would like to double down on the original question @skarnet :
could you please confirm that marking a longrun service down (in order to do a deferred manual start by calling s6-rc -u at some point later) at start-up is NOT possible in v3?
merci
I do not confirm that, because it's not true!
If you define the service, but do not make it a part of the user
bundle, then it will not be started at container start time, and you can start it later on via s6-rc -u change myservice
.
ah, impecc, it can be so simple.
after removing the service from the user bundle it has exactly the behaviour is was looking for.
i had understood what's not in the user bundle is not available at all later. good that i misunderstood.
bonne année!