Re: experiment: making a shim for SysV-styled installs using rc scripts

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Fri, 14 Oct 2016 10:22:29 +0000

>What if you could keep the existing structure and "service foobar
>whatever"
>scripting, but replace the actual /etc/init.d scripts with a shim, one
>that
>would activate the appropriate daemon and invoke supervision when you
>called it? A few of the existing problems would go away - there would
>be a
>real supervisor and no stale PID files, etc. In effect, gluing the
>supervisor to the existing framework eliminates some of the most
>glaring
>issues.

  Yes, I think that's the right idea - it's the only way to help distros
smoothly transition from a sysvrc-style init to a supervision-style
init.
What is missing or incomplete in existing service managers is the
underlying
infrastructure; their interfaces are decent and can be worked with.


> I hacked together a little script to try it out. The issues I've
>immediately run into are:
>
>* things like "reload" won't work, because there really isn't a
>consistent
>method of signalling a daemon to "reload its settings". The closest I
>can
>get is to map "service foobar reload" to having a SIGHUP sent to the
>daemon
>being supervised.

  Yes, that's normal. Anything more than start/stop/restart/status and
the
script has to be service-dependent. It's the case for sysvrc-style
startup
scripts too.


>* you still have all the restrictions of the structure of the system,
>i.e.
>6 runlevels, no parallel startup, etc.

  Yes, but that's dependent on the service manager. In order to fix that,
you need to switch to a service manager that doesn't have those
restrictions;
that's a different step, that can be performed later.


>I'm still exploring this a little bit. Would this shim have any real
>value, other than to help transition older systems into a full
>supervisor-plus-system-state-manager? Comments and ideas?

  I'm not sure whether it has intrinsic value - except, I guess,
compatibility for people who want to use a supervision framework but
still
keep their service manager - but it's undoubtedly the right way to
transition systems to a supervision framework, and that's enough of a
reason to work on something like that. :)

--
  Laurent
Received on Fri Oct 14 2016 - 10:22:29 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC