Is there a way to create and start up new services in v3 after the container is running?

[paul-upfeat]

Hi there,

I've been trying to look up if it was possible to basically start up new managed services/processes after the container is already running. I've tried searching through various things and reading the docs and come to the conclusion that it probably isn't possible in v3 due to the way s6-overlay starts up compared to v2 - but wanted to confirm.

In v2 I was basically able to do something like:

• create a new run file with a script that contained a long running process in /etc/services.d/myservice
• run something like s6-svscanctl -an /etc/services.d that would rescan the service dir and start up the new service

In upgrading to v3, I got a bit lost. The understanding I got was the service db is created and compiled during the init process and you can't really change it after. The documentation specifically says:

In particular, you should not try to run the s6-svscanctl -t /var/run/s6/services command - it will not work anyway because the supervision tree has changed locations.

and when running s6-svscanctl or related commands I basically get an error saying supervisor not listening

Is something like this still possible/recommended?

Thanks!

[skarnet]

What you cannot do in v3 - not without hacks, at least - is dynamically change the startup sequence: the point of using s6-rc is to make it as static and reliable as possible.

However, the s6 infrastructure is still there, and if you want to create new (longrun) services to be supervised by s6, you can.

• Create your new service directory in (for instance) /var/services/foobar.
• Run s6-svlink /run/service /var/services/foobar. Your new service will be started and supervised.

The scan directory is now /run/service; but absolutely do not run s6-svscanctl command on it aside from -a and/or -n, else you may interfere with the regular s6-overlay shutdown mechanism. Even then you shouldn't need -a or -n, because you can use the s6-svlink and s6-svunlink commands instead - that is safer.

/run is not persistent, and it is a voluntary design decision in v3 to run the supervision tree in a non-persistent place. If you want persistent service directories, store there in a persistent filesystem; a subdirectory of /var generally works, but if your rootfs is not read-only, you can store service directories anywhere you like.

Note that we do not recommend doing what you want to do, because for maximum reproducibility we advocate for the fewest possible moving parts. But all the s6 functionality is definitely there in v3, and if you know what you're doing, you're welcome to use it.

[paul-upfeat]

Works like a charm, thank you very much.

Appreciate the quick replies and all the work you're doing, cheers!