On 29/09/2015 00:08, Buck Evan wrote:
> If it's not good for s6, I'm not sure it's good for my framework either.
Not necessarily. s6-supervise is extremely paranoid; depending on its
use cases, your framework doesn't have to be. Also, if you control both
ends of a named pipe and can reasonably assume that nobody's going to
mess with them, that's a lot safer than having a named pipe as part of
a public interface.
> Would this be a good candidate for the ftrig* stuff?
> It does seem like event notification.
fifodirs internally use named pipes ;) That would probably make your
interface more complex than it needs to be.
> Or: How do you pass a file descriptor such that it can be used by a parent
> process?
By fd-passing, which is black magic over a Unix domain socket. You need
your client (child of ./run) and your server (your framework) to
communicate over a Unix socket (have the server listen and accept to
some socket in the filesystem, have your client connect to it), and
there are functions to magically copy a descriptor from one to the other.
Google "fd-passing".
I have functions in skalibs to make it easier to transfer fds along
with text over a stream socket: unixmessage.h
See s6-sudoc.c and s6-sudod.c for a relatively simple usage example.
> 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.
'Your run script must be called "./run.framework" no matter what'
'If you want poll support, write a ./ready script'
Then automate the creation of ./run files that will just exec
"my-poll-helper ./run.framework". And my-poll-helper tests for ./ready
scripts and does what it needs, just executing into its argument if
there's no valid ./ready script. You don't even need to connect
my-poll-helper to the framework in that case: you can just have it
do its ./ready polling in the background and write a newline to
notification-fd when it succeeds, as we talked about earlier.
Wrapping ./run gives you a lot of freedom.
> An svc --hey-im-ready option would continue that trend.
Using s6-supervise's control pipe as the mechanism to report
readiness. Yes, that's a possibility, and I thought about it, but
ultimately rejected it, because s6-svc sends orders to control the
service, not to fake its state.
s6-supervise tries to always report the *real* state, not an
arbitrary state defined by the user. You have to realize that all
this discussion is about an attempt to make s6-supervise report a
fake state when the daemon doesn't have support: no wonder it's
difficult! I didn't make it intentionally difficult, but I didn't
design the thing around making it easy to fake states, either.
A s6-svc option to fake a state would make it a bit *too* easy for
my taste.
Wrap the goddamn run script. It's by far the easiest way to get
what you want.
--
Laurent
Received on Tue Sep 29 2015 - 13:24:18 UTC