Re: Could s6-scscan ignore non-servicedir folders? [provides-needs deps]

From: post-sysv <boycottsystemd_at_openmailbox.org>
Date: Thu, 22 Jan 2015 14:40:12 -0500

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.
Received on Thu Jan 22 2015 - 19:40:12 UTC