>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
Received on Thu Feb 02 2017 - 22:21:45 UTC