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 anyway.
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. -- Laurent