If you have a choice of what Docker calls as PID1, why not just have it
call the runit executable, which will call sv's for level 1 and 2 and
then run runsvdir. Then you have a PID1 that does all the right things.
On Thu, 2 Feb 2017 00:34:48 -0800
Mitar <mmi...@gmail.com> wrote:
> It depends how once organizes its container, but it is pretty normal
> that one calls runsvdir as the PID 1 in the Docker container. So that
> Docker runtime, when it is creating the container, calls directly the
> runsvdir on one directory, which contains all the services inside the
> Docker container.
> On Wed, Feb 1, 2017 at 9:55 AM, Steve Litt
> <sl...@troubleshooters.com> wrote:
> > On Wed, 1 Feb 2017 12:09:01 -0500
> > Roger Pate <ro...@qxxy.com> wrote:
> >> On Wed, Feb 1, 2017 at 11:48 AM, Laurent Bercot
> >> <ska-skaw...@skarnet.org> wrote:
> >> > You want a clean process tree with a visually pleasing "ps
> >> > afuxww" output? Fix your services so they don't leave orphans in
> >> > the first place. ...
> >> > Reparenting orphans to anything else than the default is a
> >> > backwards way to solve a nonexistent problem.
> >> Name it reaperhack:
> >> reaperhack is what it says: a hack. Ideally, you should never
> >> have to use it. It is only useful when you want to supervise a
> >> daemon that results in orphans; and even then, the right thing is
> >> to report this as a bug to the author of the program leaving
> >> orphans and have it fixed.
> > Am I missing something? Do containers not have a PID1? If so, what
> > runs runsvdir (with the runit init system)? What starts up whatver
> > sv script?
> > Thanks,
> > SteveT
> > Steve Litt
> > January 2017 featured book: Troubleshooting: Just the Facts
> > http://www.troubleshooters.com/tjust