Re: readiness notification from non-subprocess

From: Buck Evan <buck_at_yelp.com>
Date: Mon, 28 Sep 2015 14:26:20 -0700

I'm writing a webdev-friendly(er) framework on top of s6, and would like to
add ./check support in my layer of code.
In order to do that, I need a state machine that looks for the file, if it
exists, enter into a polling state machine.
That bit's fine.

When my state machine sees that ./check has succeeded, what will it do?
I can't use the current notification-fd interface because I'm in an
unexpected bit of the process tree; this is external program sitting *on
top* of s6-supervise. It's the parent process.

I can see that my named-pipe suggestion is flawed. I'm quite willing to
drop that.
Can we add a svc -<letter here> option that tickles the same bit of code?

Or, can we make it simpler for me to do what s6-supervise does when it gets
the notification-fd signal?
It seems to do two things, send a U signal to ./envents/; I can do that.
It also updates the state in ./supervise/status; that I can't do, without
writing buggy code.
I think implementing this would also consist of a new svc -X option.

I can get around this by writing a shim that goes in front of any users'
service that want to use this feature, but that has usability issues that
I'd like to avoid.


On Mon, Sep 28, 2015 at 2:09 PM, Laurent Bercot <ska-skaware_at_skarnet.org>
wrote:

> On 28/09/2015 22:49, Buck Evan wrote:
>
>> If i'm reading the code correctly, readiness notification currently works
>> via a unnamed pipe between s6-supervise and its supervised subprocess. I'd
>> like to tell s6-supervise that my service has become 'ready' from a parent
>> process, which of course doesn't have access to that named pipe.
>>
>> I realize this is highly unusual and possibly a problematic design on my
>> part, but I think this would be a reasonable feature; could we promote
>> that
>> anonymous pipe to a named pipe under supervise/, please?
>> supervise/notification seems like an obvious choice.
>>
>
> I'd rather not, if it can be avoided, for safety reasons. The less
> s6-supervise interacts with user-controlled filesystems, the better -
> this is the reason why it took me so much time to implement
> timeout-finish support: I wanted to do it in a way that could not
> fail. Named pipes are fickle creatures, and I don't trust users to
> handle them correctly (dumb example: busybox grep does not play nice
> with them, I'm not sure about GNU grep) whereas a pre-opened fd is
> relatively safe - only the daemon and its children have access to it,
> and there aren't many possible misuses.
>
> IOW: the restriction is intentional.
>
> Could you please describe a little more what your setup is? I'm
> sure we can find solutions to your problem that don't involve relaxing
> the restriction.
>
> --
> Laurent
>
>
Received on Mon Sep 28 2015 - 21:26:20 UTC