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
