On 01/22/2015 02:36 PM, Avery Payne wrote:
It has been my feeling that the optimal service supervision scheme
would eschew
the concept of a dependency system completely, and instead rely on
some form
of lazy/delayed execution, performing heavy use of queueing with no
explicit
dependency configurations whatsoever.
This is the existing supervision behavior. It's also quite messy as
services struggle to get started until their own dependencies are met,
and takes a little more time. All I'm doing is offering to bring
order to the chaos, nothing more than that. And that offer is
entirely optional.
I know inetd/ucspi-tcp can provide
this effect to a limited degree, but its use hasn't been too
impressive thus far
(systemd has overhyped it significantly). Alternative ideas still
escape me, but
I'm trying to research concepts from related fields like distributed
systems
(provisioning, service discovery, clusters, 9P/namespaces/Plan 9, so
forth)
in the hope of coming up with something.
I'm having a hunch it'll involve setting up a way for daemons to
communicate
by a superserver through the use of a persistent data store (be it a
file
server, a task queue or whatnot). Starts to border on service
discovery, but
simpler and more ad-hoc.
In general, the idea is to provide a mechanism for synchronization
that will
displace dependencies, getting the same intended result.
I'd be interested to see the result. I'm not against using something
else, and maybe something else will emerge. But for the moment, I
have a pragmatic stance that is oriented towards getting people to
want to use supervision.
To the best of my knowledge, existing supervision behavior has no
queueing (unless you
optionally integrate with s6-networking, nosh's accept/listen programs
or some other
ucspi-tcp/inetd variant) or any other form of lazy execution, and as I
stated the
superserver approaches still remain underdeveloped and lacking.
My hypothetical scheme will likely be part of a new system, not as an
add-on to an
existing one.
