Re: readiness notification from non-subprocess

From: Buck Evan <buck_at_yelp.com>
Date: Mon, 28 Sep 2015 15:08:32 -0700

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

> On 28/09/2015 23:26, Buck Evan wrote:
>
>> 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.
>>
>
> Can't you modify or wrap the run scripts to fork a process to do that
> kind of management?
>
> My idea:
> * the run script forks a child
> * the parent closes notification-fd then execs into your daemon
> * as we already mentioned, I'd simply do all the ./check stuff in the
> child, but if you don't want to do it that way: the child communicates
> with your framework somehow
> * when your framework completes the polling, it tells the child OK
> * the child then writes a newline to notification-fd then exits
>

This is nearly what I have implemented right now.
I'm trying to improve on that.
My original plan for "communicate somehow" was a named pipe, and my
original email was an attempt to get that feature moved upstream to s6, but
we've agreed that's not so good.
If it's not good for s6, I'm not sure it's good for my framework either.
Would this be a good candidate for the ftrig* stuff?
It does seem like event notification.



>
> Other idea, more complex but maybe more flexible:
> * you write a "frameworkify" tool you can prepend your run scripts with
> * frameworkify connects to your framework via a Unix socket, passes
> notification-fd to it, closes notification-fd and the socket, then
> executes into the rest of your run script
> * your framework has the fd, do whatever you want
>

Ah my understanding of an fd is just an integer which the kernel will honor
as a file, when referenced from that process.
If I get that integer into my framework, I don't see how I can use it.

Or: How do you pass a file descriptor such that it can be used by a parent
process?



> What do you think?
>
>
> 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.
>>
>
> Ah.
> I really, honestly, firmly believe that ./run wrappers are totally
> the way to go when you want to add features to service directories. It's
> the way s6-rc works and it's the way I plan to base new features on.
> Can we talk about your usability issues instead, to see if we can work
> around them?


I'd need to document "you need to write a ./ready script *and* prefix your
service with my-poll-helper".
If I can get this down to just one thing that people have to do right, it's
going to work better.

I agree that adding features to a service should involve editing their
./run script, but my goal here is a bit different; I'm trying to add a
feature to s6-supervise. So far that's been quite easy, between svstat and
svc I have read/write access to all of supervise's state that I've wanted.
An svc --hey-im-ready option would continue that trend.
Received on Mon Sep 28 2015 - 22:08:32 UTC