What if you could keep the existing structure and "service foobar
scripting, but replace the actual /etc/init.d scripts with a shim, one
would activate the appropriate daemon and invoke supervision when you
called it? A few of the existing problems would go away - there would
real supervisor and no stale PID files, etc. In effect, gluing the
supervisor to the existing framework eliminates some of the most
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
What is missing or incomplete in existing service managers is the
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
method of signalling a daemon to "reload its settings". The closest I
get is to map "service foobar reload" to having a SIGHUP sent to the
Yes, that's normal. Anything more than start/stop/restart/status and
script has to be service-dependent. It's the case for sysvrc-style
* you still have all the restrictions of the structure of the system,
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
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
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. :)