On Thu, 29 Jun 2017 19:57:55 -0300
Guillermo <gdiazhartu...@gmail.com> wrote:
> 2017-06-29 1:43 GMT-03:00 Steve Litt:
> > On Wed, 28 Jun 2017 22:31:12 -0300 Guillermo wrote:
> >> But then you end up with an unsupervised runsv process,
> >> disconnected from the rest of the supervision tree...
> > I'm not sure about the unsupervised part of it, but I know if the
> > executable ends another one is run within a second, and I know that
> > you can turn the executable on and off with
> > sv [up|down] /var/svlink/gnumeric
> The executable (gnumeric) is supervised, the supervisor (runsv) is
> not. Sure, all those things are true, but while the supervisor is
> alive. Kill runsv (if launched in this way) and see what happens.
The runsv executable is pretty robust, so it's unlikely to die. As far
as somebody killing it accidentally or on purpose with the kill
command, that's a marginal case. But if it were *really* important to
protect against, fine, have one link dir per early longrun, and run an
individual runsvdir on each of those link directories. So now you have
the same opportunity to kill each early longrun's supervision as you
have to kill the main supervision. I think that's huge overkill, but it
could be done.
Which is the real beauty of daemontools-inspired inits: They're just
POSIX, so a halfway savvy admin can mold them to his or her exact
June 2017 featured book: The Key to Everyday Excellence