On Thu, Aug 13, 2015 at 11:40 AM, Laurent Bercot
<ska-skaware_at_skarnet.org> wrote:
> You like to play with fire. :)
> Until it's released, it's not production-ready by any means.
> Just making sure you're very much aware of that.
>
It's how I roll. Plus the backout path to a functional system takes a
few minutes in a getty. I'd feel a lot more nervous if I didn't have
physical access to the hardware.
>
> But now that I have s6-fdholder-daemon and an infrastructure to
> handle dependencies between oneshots and longruns, I don't need
> to use the pipes provided by s6-svscan anymore.
>
> - Now: the user declares a producer/consumer pair, or more
> generally, a pipeline of services: a service can have both a
> producer and a consumer, and that just means it will be in the
> middle of a pipeline. s6-rc-compile identifies pipelines, adds
> autogenerated oneshots to create pipes and store them into a
> fd-holder, and sneakily modifies the longruns so they retrieve
> the pipes from the fd-holder. It crafts the correct dependencies
> and wraps everything in a bundle, so all the shenanigans are
> invisible from the user. There will still be an indestructible
> pipe between a producer and its consumer; it just won't be held
> by s6-svscan. And there aren't any foobar/log service directories,
> which should make s6-rc-update a lot easier to write.
>
I'm not sure how I feel about having the indestructibility guarantee
residing in a service that isn't the root of the supervision tree. I
haven't done much with s6-fdholderd but unless there's some extra
magic going on in s6rc-fdholderd, if it goes down it won't be able to
re-establish its control over the overall communications state due to
it creating a fresh socket. I know, I know, it should be fine, but
accidents happen.
In the simple world where s6-svscan was the pipe holder, an accident
that hosed it would also hose the supervision tree, and the logging
guarantee stays that. It seems now that if s6-fdholderd gets restarted
and then a full logger process gets restarted (s6-svc -dx $svc-log),
there will be nothing to re-establish the pipe between $svc-svc and
$svc-log since s6-fdholderd has forgotten about it.
It may be indestructible still, but it's a lesser guarantee of
indestructibility.
>
> The autogenerated bundles are there for the user's convenience,
> they simply represent a whole pipeline, so yes. You can choose how
> they're called, and you can have dependencies to them.
> The only thing you can't do is have an explicit dependency to an
> autogenerated atomic service, with a name that starts with s6rc-.
> Those are part of the s6-rc-compile mechanism, they're not visible
> from the source.
>
That's fine, I was mostly just making sure that from the compiler's
standpoint an autogenerated service and a manually defined service are
treated the same.
>
> This is all subject to change before the first release, but I
> think the design is pretty sound, so it probably won't move much.
>
Cool.
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Thu Aug 13 2015 - 23:25:18 UTC