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
Received on Mon Mar 23 2015 - 12:16:32 UTC