Hm, when I read the runit man page I got scared because of its trying
to reboot and halt the machine. I am not sure how will that interact
with a Docker container.
Don't worry about that. When run from an unshared PID namespace, the
reboot() system call is diverted by the Linux kernel and does not
really reboot, it just kills the pid 1 in that namespace (so it will
stop your Docker container).
I also didn't want one extra process to be in
every container. But you are right, it seems it might be necessary
Processes are not a scarce resource. Running more processes on a Unix
system is not a problem - Unix systems were _designed for that_.
What are scarce resources are RAM and CPU, which runit, s6, and other
supervision systems, use very sparingly. If you use runit as pid 1
instead of trying to have runsvdir be pid 1, you will make your life
easier and not notice the difference.
(You should still check s6-overlay as John advises. You would then get
the best of both worlds, with s6-svscan (the equivalent of runsvdir)
running as pid 1. ;))
So, let 'see. I could simply then use runit as PID 1 inside a Docker
image. /etc/runit/1 could be an empty script (is it even required to
have it, if not needed?). /etc/runit/2 would then start runsvdir.
Should it exec into it?
No, because you need stage 3 to clean up everything at shutdown time.