On 13/08/2015 19:44, Colin Booth wrote:
> I run s6-rc on my laptop, which is about as half-serious an
> environment as you get.
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.
> I may be missing something, but the auto-generated log service doesn't
> seem to be a thing yet. Or is that all under-the-hood changes and the
> filesystem interface hasn't changed.
There no such thing as an auto-generated log service, and there
can't be. What has changed is how logged services are compiled.
- Before: the user declared a producer/logger pair, and
s6-rc-compile arranged for the service directories to be
producer and producer/log. The pipe between the producer and
the logger was created and maintained by s6-svscan.
The problem with that approach is that I pulled my hair out
for a week trying to figure out what s6-rc-update should do
with the service directories when the producer needs to restart
and the logger does not, and stuff like that, given that if
you don't want to restart a service, the service directory has
to *keep the same inode*, else s6-svscan goes bonkers. Yeah,
it's much harder than it looks.
s6-svscan's ad-hoc management of logged services is pretty neat
when it's all you have. It's a free pipe creator and fd-holder
for the pipes. But it creates a dissymmetry in the services, which
seriously gets in the way when you have automation that moves
service directories around. You can't do what you want with
producer/log, or even with producer; the services are intimately
coupled, and it needs specialcasing everywhere in the automation,
which is too hard and too ugly.
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.
> Gotcha, makes sense. I'm still glad to get rid of my explicit
> service-logger bundle directories. I'm assuming though that an
> explicit bundle can call out an autogenerated bundle as a requirement?
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.
> So for example an autogenerated sshd bundle (containing sshd-srv and
> sshd-log) can be called out in an explicit lan-services bundle.
Yes. "echo sshd > sshd-srv/pipeline-name" will tell s6-rc-compile
to make a bundle named sshd, for the whole pipeline that starts
with sshd-srv.
That bundle, in your case, will contain sshd-srv, sshd-log, and an
autogenerated oneshot named s6rc-storepipe-sshd-log, which you can
examine via s6-rc-db if you're curious.
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.
--
Laurent
Received on Thu Aug 13 2015 - 18:40:37 UTC