Some more comments:
- in init: keep the redirfd and the fdclose lines before running
/etc/s6/init-2. If you don't, you'll have a race condition and
init-2 may run before your services are up. The redirfd line
is there to block until one of the services is up. If you are not
running s6-fdholderd, replace the path with
/etc/services/$something/supervise/control , $something being one
of your services.
- if your services are all started when s6-svscan starts and you
are not running any kind of dependencies, you can remove the first
"if" block in your /etc/s6/init-2. The s6-svscanctl -a command is
only useful when you populate the scandir in stage 2; if your scandir
is already populated when your stage 2 starts, you don't need it.
- s6-setsid is called with the -q option so it does not needlessly
complain when a command is given without a controlling terminal. Or
in other cases that don't come to mind. The point is that it needs
to be run in some cases and not in others, so running it with -q is
the simplest way to get the correct behaviour in all cases.
- in /etc/services/.s6-svscan/crash: since you're in a container,
it's not a real problem if pid 1 dies; so if you just want to fail
loudly and die instead of executing a shell, you can. Run "exit 1"
or whatever exit code you want. "exit ${?}" is only valid after
an "import ?" command and would only give you the exit code of the
latest foreground command.
- in /etc/services/.s6-svscan/finish: the difference between
foreground and if is that if exits if the command in the block exits
nonzero, whereas foreground just puts the exit code into the ? variable
and goes on. This script is your general finisher, and you don't want
to abort if something goes wrong, you want to keep finishing: that's
why there are "foreground" instead of "if" commands.
"fdclose" and "s6-sleep" are not in foreground blocks because they
work without foreground blocks: after they do their job, they *exec*
into the rest of the script. foreground blocks are there to encapsulate
commands that *exit* after doing their job.
- I can't remember all the functionality in the overlay, I'm not sure
of exactly what features or guarantees you lost with what you stripped.
Gorka or John, who maintain the overlay, will probably be able to tell
you more. I do remember that the most painful part was making sure that
the supervision tree was always run with a safe environment and safe
descriptors, while the user command was always run with the
user-provided environment and user-provided file descriptors.
> Yes, I can make those guarantees in this case. Can you recommend any
> changes for failing loudly if this should prove incorrect in the
> future? This is preferably to silently fixing file and directory
> attributes as s6-overlay does currently.
Oh, don't worry, if something goes wrong with your scandir, since
your stderr points outside of the container, the failures will be
loud enough. You'll wish those pesky s6-supervise processes would
stop spamming your logs. :)
--
Laurent
Received on Thu Apr 23 2015 - 00:13:47 UTC