Hi Aristomenis ! Thanks for your comments. My replies in-line.
1) The S6 docs (http://skarnet.org/software/s6/ <http://skarnet.org/software/s6/>) direct me to read the INSTALL file in a tarball, and then link to 10(!) different s6-* subprograms. This is too much to digest. I'd love to see a quick start guide.
I agree. The existing documentation is intended as a reference, and it is perfectly accessible to people who have heard of supervision before and know more or less what to expect; however, if you are new to supervision, I understand that it can be confusing. What is lacking is an overview, a tutorial and a step-by-step guide. I'm not good at writing those - and, to be perfectly honest, working on more documentation instead of the next piece of code (which should make all of this simpler to use) sounds like a daunting task to me. You're not the first one to report the difficulty of getting past the initial bump; I know it's there, and I should address it. It's just a question of mustering up the time and the courage to do it, because writing a good tutorial is hard, and time-consuming. A simple overview should help already; I'll try and write one sooner rather than later.
2) Mirroring the S6 code to Github is a nice idea which Laurent mentioned in the previous thread. Laurent, may we start posting issues to the https://github.com/skarnet/s6/ <https://github.com/skarnet/s6/> repo? In particular, I'm having some trouble which I describe in a later bullet point.
I would rather centralize the discussions here, on this mailing-list. (Or on the skaware mailing-list for technical details.) I think that scattering information and resources would be detrimental, at least at this stage of the project. Also, I really don't want to depend on github for anything else than visibility.
3) I understand the reasons behind breaking S6 up into a large set of simple utilities, but the current state of affairs is pretty extreme. ;ss /usr/bin |grep s6-* | wc -l reports 55 different utilities.
Please check your installation. It should be 56. :) (Plus ucspilogd, s6lockd and s6lockd-helper.)
Have you considered breaking s6 up into multiple packages, for example "core" and extras? That may not be feasible, so my main feedback is that the larger the number of utilities provided, the greater the handholding necessary to get users up to speed.
Yes, I understand. s6 had a lot less executables up until the recent releases, because, as you said, it was more broken up: all the Unix domain socket management stuff was in the s6-networking package. The addition of the s6-fdholder series of programs, which was necessary to claim that s6 can perform "socket activation", forced me to integrate more executables into the s6 package itself. I can't say I like it, but it's really a lot simpler that way. And I agree with your conclusion: a tutorial would help. At some point, I'll get around to writing one, I promise. 4) I tried compiling s6 in an
Ubuntu container. ./configure froze while looking for /dev/random. You can ctrl+c through this step, but this won't work when running docker build, because it's noninteractive. Is there a way to bypass this step?
Give the --enable-force-devr option to ./configure when compiling skalibs. 5) For major distributions and usage mediums (Ubuntu,
docker, OS X, and perhaps Alpine/busybox), the docs should provide clearer steps for installation and usage. John recently posted an Alpine package, which is great. But the version available in Ubuntu is extremely old - 0.47. Have you considered adding a Launchpad PPA?
Sorry, but this is a can of worms I'm not going to open. The world of Linux distributions is a shark tank, and my very strong opinion is that the sheer amount of them - as well as the politics and corporate that govern most of them - is hurting software a lot, and ultimately is hurting users. I could ramble for days about why I think so, but the point is that I will not explicitly support or favor one distribution over another. If I added a Ubuntu Launchpad PPA, I would have to add equivalent support for every distribution out there, and not only the mainstream ones. This is simply not feasible. Providing working tarballs and possibly a git repository is the job of software authors, and I will do my best to ensure that the software works, and to listen to suggestions. Providing packages is the job of *packagers* (duh), and I have neither the time nor the inclination to be a packager. If anyone wants to provide a Launchpad PPA for s6, or the equivalent for any other distribution, I'll be very happy and grateful about it, of course. John's work of providing s6-based container images for various distributions is invaluable.
6) Gorak/John: None of the s6/skalibs images are explicit about /etc/leapseconds.dat. This confuses me. When reading through the build scripts, the file is usually copied into the image, but I can't find the original leapseconds.txt. Is the original, out-of-date version from libtai being used? If so, this needs to be updated.
When you install skalibs, it provides its own version of /etc/leapsecs.dat. It is up-to-date. The file provided in the overlays should be the one coming from skalibs. 7) s6-svwait (and possibly other s6-* utils) throws a really
unhelpful error if run against a directory which hasn't yet had s6-svscan run against it: "fatal: unable to subscribe to events for/service: No such file or directory".
Yes, it is a programming error to run s6-svwait on a service directory s6-supervise is not yet running on. I will make it clearer.
It was also initially unclear to me that svwait should be run against the individual service directory, rather than the parent services directory.
I will make it clearer as well. Thanks for the feedback.
8) I'm really struggling to get a "simple" flow up. (...)
Getting things to work in both interactive and noninteractive case, while allowing people to both run commands inside a container and simply start a container without running a command, is Complicated (tm). We have been working on it in the past few weeks; it's still a WIP. If you are using s6-overlay-builder, https://github.com/just-containers/s6-overlay-builder then it should work as intended if you are using /init as ENTRYPOINT. For questions specific to that overlay, you can use the github Issues thingy, since that's where it's hosted ;)
9) This has already been discussed a bit, but I'd like to add another vote for allowing s6-svscan to run a command.
You can't quite use s6-svscan as a direct ENTRYPOINT, you have to perform a little work around it; this is the point of /init. (Indeed, if you use s6-svscan as ENTRYPOINT, the whole supervision tree will get your terminal as a controlling terminal, if you launch the container with one; this is not what you want.) The s6-overlay-builder project should provide you with the features you need, if you use /init as an ENTRYPOINT. Gorka will have more details than I do about the specifics of the overlay, and the images created via this overlay. Thanks again for your comments; they will be taken into account. I doubt my answers have been very helpful, but if you have specific questions about s6, feel free to ask ! -- Laurent
