From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2356 Path: news.gmane.org!.POSTED!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: [Announce] s6.rc: a distribution-friendly init/rc framework Date: Thu, 22 Mar 2018 17:10:58 +0000 Message-ID: References: <20180322132334.GA11596@caspervector> Reply-To: "Laurent Bercot" NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1521738538 27935 195.159.176.226 (22 Mar 2018 17:08:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2018 17:08:58 +0000 (UTC) User-Agent: eM_Client/7.1.31849.0 To: supervision@list.skarnet.org Original-X-From: supervision-return-1947-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Mar 22 18:08:54 2018 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ez3hs-0007BD-BB for gcsg-supervision@m.gmane.org; Thu, 22 Mar 2018 18:08:52 +0100 Original-Received: (qmail 25139 invoked by uid 89); 22 Mar 2018 17:11:26 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25132 invoked from network); 22 Mar 2018 17:11:26 -0000 In-Reply-To: <20180322132334.GA11596@caspervector> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrudelgdekfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucffohhmrghinhepghhithhlrggsrdgtohhmpdhsmhgrrhguvghnrdhorhhgpdhskhgrrhhnvghtrdhorhhgnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtnecuvehluhhsthgvrhfuihiivgeptd Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2356 Archived-At: >s6.rc [1] is an attempt to bridge the gap between the elegant=20 >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] . 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=C3=A9lie or Alpine (which are the most likely to use it first). But ther= e 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