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
