Re: Build Break in s6-rc
On 14/08/2015 01:25, Colin Booth wrote: 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. I've thought about it for a while, and finally decided that the advantages overshadowed the drawbacks. First, the only time this makes a qualitative difference is when the pipe maintainer cannot die at all. In one setup, you lose your pipe when s6-svscan dies; in the other setup, you lose your pipes when s6-fdholderd dies. The only way to prevent that is to forbid your pipe maintainer from dying entirely. Second, the only way to do that is to put the pipe maintainer as process 1; but I don't think putting things in process 1 to make them indestructible is the answer. It's the systemd way. We're process 1, so we cannot die, and we can do everything on the system that needs reliability. Granted, it's a nice thing to have, and I do advocate the use of s6-svscan as process 1, but not because it's a pipe maintainer. I use s6-svscan as process 1 because it's the natural place for the root of a supervision tree; and everything else is a bonus. The logged service feature of s6-svscan is a direct legacy of daemontools. It was very cool at the time because we had nothing else; and I keep it because there's a large daemontools user base, and breaking compatibility would not make sense because the code that handles logged services isn't complex enough to be a maintenance burden. (And still, it is one of the very few places where I had to write a detailed comment labelled BLACK MAGIC, because there *is* some complexity to it.) So it's not going away any time soon, but it's still a legacy ad-hoc functionality. If I was writing s6-svscan today, I would not implement this feature; I would advertise the use of a dedicated fd-holder instead. And that would cut the code size of s6-svscan by a non-negligible amount, getting it closer to the ideal of the minimal process 1. The correct approach to reliability is not to try and force processes not to die; and it's not to cram more stuff into the only process that cannot die. It's to make sure it's not a serious problem when processes die. And that, btw, is exactly what supervision is about in the first place. So, let's make sure it's not a problem when the pipe maintainer dies. In this case, let's add a watcher for s6-fdholderd. Instead of oneshots that store pipes into the s6-fdholderd, how about filling up s6-fdholderd at start time with all the pipes it needs ? The processes in a pipeline will keep using the old pipes until one of them dies, at which point the old pipe will close, propagating the EOF or EPIPE to the other processes in the pipeline; eventually all the processes in the pipeline will restart, and fetch the new set of pipes from s6-fdholderd. That sounds reliable to me, and even cleaner than the current approach, where the services can't reliably restart if s6-fdholderd has died; and it doesn't need additional autogenerated oneshots. (Thanks for the rubber duck debugging! That's a huge part of why I like design discussions.) So yeah, if s6-fdholderd dies, and one process in a pipeline dies, then the whole pipeline will restart. I think it's an acceptable price to pay, and it's the best we can do without involving process 1. -- Laurent
Re: s6-rc plans (was: Build break in s6-rc)
On Thu, Aug 13, 2015 at 9:46 AM, Laurent Bercot ska-skaw...@skarnet.org wrote: Oh, and btw, I'll have to change s6-rc-init and go back to the the directory must not exist model, and you won't be able to use a tmpfs as live directory - you'll have to use a subdirectory of your tmpfs. Ah bummer. It was fun while it lasted. The reason: as it is now, it's too hard to handle all the failure cases when updating live. It's much easier to build another live directory, and atomically change what live points to - by renaming a symlink. And that can't be done if live is a mount point. Makes sense. In this case can we get a --livedir=DIR buildtime option so us suckers using a noexec-mounted /run can relocate things easily without having to type -l livepath every time we want to interact with s6-rc? Cheers! -- 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
s6-rc plans (was: Build break in s6-rc)
Oh, and btw, I'll have to change s6-rc-init and go back to the the directory must not exist model, and you won't be able to use a tmpfs as live directory - you'll have to use a subdirectory of your tmpfs. The reason: as it is now, it's too hard to handle all the failure cases when updating live. It's much easier to build another live directory, and atomically change what live points to - by renaming a symlink. And that can't be done if live is a mount point. -- Laurent
Re: Build Break in s6-rc
On Thu, Aug 13, 2015 at 9:37 AM, Laurent Bercot ska-skaw...@skarnet.org wrote: Eh... keep a backup of your current source, if you're using it in a half-serious environment. The current version uses automatically generated services, and the scripts haven't been tested yet, it's the first draft. I run s6-rc on my laptop, which is about as half-serious an environment as you get. I went back and changed the way s6-rc-compile handled producer/logger pairs, because logged services were too much of a pain to correctly manage in s6-rc-update: it became insanely complex to compute when a service directory can be kept and when the service has to be stopped and restarted. Doing away with logged services makes the update procedure more straightforward. 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. But since a pipeline now includes autogenerated services, there needs to be a bundle containing everything, for easy takedown. So, autogenerated bundle, too. It's beautiful and scary at the same time - I feel like complexity can get out of control fast. 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? So for example an autogenerated sshd bundle (containing sshd-srv and sshd-log) can be called out in an explicit lan-services bundle. I'd test it out, but I don't have time right now to re-do all my logger producer/consumer files so a recompile will break. Cheers! -- 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
Re: Build Break in s6-rc
On Thu, Aug 13, 2015 at 11:40 AM, Laurent Bercot ska-skaw...@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
Re: Build Break in s6-rc
On 13/08/2015 18:05, Laurent Bercot wrote: If you're going to pull from git head, then you should pull from the git head of *every* project, including dependencies. Which you didn't for execline. :) I'm not lying! I'm just chronologically challenged sometimes. See, if you had pulled from the execline head from the future, i.e. from now, your build wouldn't have broken. Really! -- Laurent
