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
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
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?
--
Laurent
Received on Mon Sep 28 2015 - 21:50:03 UTC