Blits - blitterated/docker-dev-env-s6 GitHub Wiki
These don't really belong anywhere. They're mostly just temporary notes. Mostly.
They're called blits because I've moved a chunk of memory around.
Running Additional Processes in a Container
Phusion suggestions
- syslog
- cron
- sshd
- runit
- setuser
My take on additional processes in container
- syslog - not needed if using S6 Overlay
- cron
- sshd
- runit - not needed if using S6 Overlay
- setuser - not sure about this one
Should a run script 'exec' into an executable?
Should run scripts use exec or not?
#!/usr/bin/with-contenv execlineb
exec gradle --foreground
vs.
#!/usr/bin/with-contenv execlineb
gradle --foreground
Here's info about the run script from the S6 Service directories documentation.
An executable file named run. It can be any executable file (such as a binary file or a link to any other executable file), but most of the time it will be a script, called run script. This file is the most important one in your service directory: it contains the commands that will setup and run your foo service. It is forked and executed by s6-supervise every time the service must be started, i.e. normally when s6-supervise starts, and whenever the service goes down when it is supposed to be up.
Here's info about the finish script from the S6 Service directories documentation.
An optional executable file named finish. Like run, it can be any executable file. This finish script, if present, is executed everytime the run script dies. Generally, its main purpose is to clean up non-volatile data such as the filesystem after the supervised process has been killed. If the foo service is supposed to be up, foo/run is restarted after foo/finish dies.
Counterpoint available here, but there's not much in the way of premises. The author just doesn't like that the run script process is the parent of the service process.
Skarnet weighs in on this at the end of his comment in this GitHub issue:
Please
execyour java invocation, though, so you don't have a shell staying around and intercepting signals from the supervisor.
And again in this GitHub issue comment
if your interpreter is a shell, you should exec the last line, so the shell is replaced with your service instead of staying around.
So does this apply if the interpreter is execline? Probably not since it essentially execs every line.