My understanding of s6 socket activation is that services should open, hold
onto their listening socket when they're up, and s6 relies on the OS for
swapping out inactive services. It's not socket activation in the usual
sense.
http://skarnet.org/software/s6/socket-activation.html
So I wonder what the "full guarantee" provided by s6 that you mentioned
looks like.
It seems like in such a world all services would race and the determinism
of the race would depend on each service's implementation.
On Tue, Apr 21, 2015 at 2:46 PM, Avery Payne <avery.p.payne_at_gmail.com>
wrote:
> On 4/21/2015 2:19 PM, Buck Evan wrote:
>
>> Does s6 (or friends) have first-class support for dependant services?
>>
> I know that runit and daemontools do not. I do know that nosh has direct
> support for this. I believe s6 supports it through various intermediary
> tools, i.e. using socket activation to bring services up, so you could say
> that while it supports it directly and provides a full guarantee, it's not
> "first class" in the sense that you can simply provide a list of "bring
> these up first" and it will do it out of the box. The recently announced
> anopa init system fills in this gap and makes it "first class", in the
> sense that you can simply provide the names of definitions that need to
> start and everything else is handled for you.
>
> Alternatively, are there general-purpose practices for breaking this kind
>> of dependency?
>>
> Strange as it sounds, renaming the child definition of a dependency chain
> (which typically translates into the directory name of the defintion) seems
> to be a regular issue. Changing the name of the definition typically
> causes various "links" to break, causing the parent service to be unable to
> locate its children by name at start-up.
>
Received on Tue Apr 21 2015 - 21:56:04 UTC