Re: readiness notification from non-subprocess

From: Laurent Bercot <>
Date: Mon, 28 Sep 2015 23:50:03 +0200

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.

  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?

Received on Mon Sep 28 2015 - 21:50:03 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC