>s6.rc [1] is an attempt to bridge the gap between the elegant
>foundation
>provided by s6/s6-rc and an init/rc system that implements the main
>functionalities beneficial for distributions. s6.rc features a
>preprocessor that generates source directories for use with s6-rc from
>given templates. The preprocessing procedure is composed of multiple
>tiny passes, which makes the preprocessor not only clean and powerful,
>but also extensible. Using the preprocessor, s6.rc supports instanced
>supervision, optional dependencies, in-place `up'/`down' scripts,
>automatic connection between services and loggers, as well as
>package-specific passes that can be plugged into the preprocessing
>phase.
Impressive work! Congratulations, Casper :)
>[1] <https://gitlab.com/CasperVector/s6rc-dotrc>.
I think the correct URL is:
https://gitlab.com/CasperVector/s6-dot-rc
I'm feeling bad asking about this seeing the amount of work you've put
into it, and I hope there's an easy way to achieve it, but: would it
be possible for you to change the name of the project?
Rationale:
- I feel that "s6.rc" is very easy to confuse with "s6-rc"; not when
it's pronounced, but when it's written. The s6 ecosystem is confusing
enough as is for non-specialists; I think I should write a general
documentation page explaining what package does what (and an index
saying which package the s6-foobar binary belongs to, for every value
of foobar). If s6 is to become popular, the confusion needs to be
reduced, not entertained; and it would be easier if software such
as s6.rc would have a more distinctive name.
For instance, "anopa" does a good job of being pretty distinctive. :)
- I obviously have no way of enforcing this, but I would very much
like to keep control of the "s6" prefix, for clarity: every package
starting with "s6" should come from skarnet.org and have a place in
the integrated s6 ecosystem. (Not to say that s6.rc does not have its
place, far from it, but I'd like people to be able to easily make the
distinction between "core" and "community".) So you're obviously
welcome to use "s6" as *part* of the name of your package, but I'd
appreciate it if the name didn't *start* with "s6".
A few miscellaneous notes:
- I now recommend using socklog[1] to implement syslogd. This is
not as elegant as having one process per syslog connection, but
socklog binds to a datagram socket, so it can be used with musl.
Having one stream per syslog client is a good thing per se because
it obsoletes the need to identify the client in every log record;
but the killer advantage would be to do away with system-wide
regular expressions for log filtering, and that's not something
we have yet. Even when you pipe "s6-ipcserver ucspilogd" into
s6-log, your s6-log script is the same for every client, so the
regexes need to be global. A real improvement would be to have
a different log script for every client connection, so the log
filtering would really be local; but I haven't yet thought about a way
to design such an architecture. That's the main reason why I haven't
much pushed for SOCK_STREAM syslog() in musl; if we can come up with a
syslogd scheme that works without any global regexes, then we'll
have a real case for SOCK_STREAM adoption. Until then, socklog works.
[1]:
http://smarden.org/socklog/
- The next piece of the s6 ecosystem that I plan to write is precisely
an integration layer for all the various existing parts: s6-linux-init,
s6, s6-rc. It will likely be called s6-frontend. It will be written
in C, and provide a user-friendly interface for setting up a complete
init system, as well as a one-stop-shop "s6" command; the goal is to
improve usability and simplicity for users who are not longtime
members of the process supervision gang.
When I went and asked distributions what functionality they needed
in order to use s6 as their default init system, this is by far the
thing they mentioned the most. So, it's in the plans. Unfortunately,
it will be some time before I can get to it, because I need to work
on money-making projects first. There is a possibility that work on
s6-frontend will be funded, but in any case it wouldn't be before one
year or two, so don't hold your breath. In the meantime, I'm very
happy that initiatives like s6.rc come to light.
- Everyone knows that I insist on the separation between mechanism
and policy, that I try to write software implementing mechanism, and
that I believe that policy is the realm of distributions. Unfortunately,
the success of a few pieces of software that embed a lot of policy -
systemd for instance, but also OpenRC to some extent - has shown that
this distinction isn't always a key factor in success, and on the
contrary, making distributors' jobs easier by embedding policy could
be an advantage. As such, s6-frontend will include a lot of policy
(where to put s6 service directories, how to organize them, where to
put s6-rc source and compiled databases, where the main scandir is,
etc.) However, if decisions about "where to put stuff" are easy enough
to take, decisions about "what init scripts should I provide, what
external software should I assume is present on the system" are
definitely not.
I see that s6.rc comes with a lot of pre-written scripts, from acpid
to wpa_supplicant. Like Avery's supervision-scripts package, this is
something that I think goes above and beyond simple "policy": this is
seriously the beginning of a distribution initiative. I have no wish
at all to do this outside of a distribution, and am convinced that
the software base must come first, and then service-specific
scripts must be written in coordination with distributions that use
it; that is what I plan to do for s6-frontend in coordination with
Adélie or Alpine (which are the most likely to use it first). But there
is a large gray area here: what is "reusable policy" (RP) and what is
"distribution-specific" (DS)? For instance, look at the way the
network is brought up - in s6.rc, in OpenRC, in sysvinit scripts,
in systemd. Is bringing up the network RP or DS? If it involves
choosing between several external software packages that provide
equivalent functionality, is it okay to hardcode a dependency, or
should we provide flexibility (with a complexity cost)?
This is very much the kind of discussion that I think is important
to have, that I would like to have in the relatively near future, and
since more and more people are getting experience with semi-packaging
external software, and flirting with the line between software
development and distro integration - be it Olivier, Avery, Casper,
Jonathan, or others - I think we're now in a good position to have it.
--
Laurent
Received on Thu Mar 22 2018 - 17:10:58 UTC