Re: s6: something like runit's ./check script

From: Jan Bramkamp <crest_at_rlwinm.de>
Date: Tue, 8 Sep 2015 13:51:16 +0200

On 08/09/15 13:24, Laurent Bercot wrote:
> On 08/09/2015 10:49, Jan Bramkamp wrote:
>> - Have one polling daemon.
>> - A wrapper registers polled services with the polling daemon.
>
> No can do, sorry.
>
> You can't make a supervision infrastructure depend on daemons,
> because daemons depend on a supervision infrastructure. The
> polling daemon would have to be supervised; of course it would
> not perform polling itself, but it would still need to be up
> every time a polling service starts. That's way too much
> bootstrap complexity and possibility of failure (with bad
> consequences) for that kind of functionality.

Only daemons requiring external polling would depend on this daemon and
it would support the s6 notification interface itself.

> Avoiding dependencies from s6 mechanisms to a daemon is the
> reason for the fifodir stuff, for instance. If I could have a
> daemon, I'd use one to pubsub notifications - it would be
> cleaner. But no.

That's why I suggested a daemon only for services lacking support for
the s6 readiness notification API.

> Also, what's wrong with a simple unsupervised background process
> that dies when its job is done?
>

If the script fails for any reason the service is stuck and won't come
up. Such simple scripts shouldn't fail but they might still run into
resource limits or other (temporary) problems. I agree that a simple
background script forked from ./run will work in >99% of the cases.

I don't like this fail-safe behavior. A polling daemon could keep its
state (except the file descriptors) in the file system and restart any
polled services in transition at the time to reacquire the file descriptors.
Received on Tue Sep 08 2015 - 11:51:16 UTC