From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2364 Path: news.gmane.org!.POSTED!not-for-mail From: Avery Payne Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: [Announce] s6.rc: a distribution-friendly init/rc framework (long, off-topic) Date: Fri, 23 Mar 2018 13:30:08 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000058989305681a4a55" X-Trace: blaine.gmane.org 1521836892 9605 195.159.176.226 (23 Mar 2018 20:28:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 20:28:12 +0000 (UTC) Cc: Supervision Mailing List Original-X-From: supervision-return-1955-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Mar 23 21:28:08 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 1ezTIG-0002Kq-31 for gcsg-supervision@m.gmane.org; Fri, 23 Mar 2018 21:28:08 +0100 Original-Received: (qmail 22185 invoked by uid 89); 23 Mar 2018 20:30:38 -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 22178 invoked from network); 23 Mar 2018 20:30:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:cc; bh=i+mEcG4ZOWBkVUU+nFKealhs7nQwwRac1L1z2Rwfdck=; b=qllkbHqygah2HD5R3EFu9WmX1aVyR8zCmfuFG1mo/ubiF81G8U7yNMhPZPyHyMF9vW ua6Cef+7RX4hyHfxOrN7XjUdjtAHaPF/l1iFd/S3fauwQw1/uAX+h8mARpEywxVXUF26 kr8gzDcWLB1xOOQ3aGY4nGhMse2/R+Sjxlp7W0D0w6YZxsMnZi1vSeY2hyL/uejdQkif eQKaOFjALngfcr706npVth+JJsGEnbdz10b08oHoXFslThhi4H/v9BNZ2lM7BXagGs+n 0ajPTi0RaK00y791nPiqBggPm23oatVhJHfOPdBAbTm+1N6zJ3ICKyssz9W5TAuI8R8i +iBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:cc; bh=i+mEcG4ZOWBkVUU+nFKealhs7nQwwRac1L1z2Rwfdck=; b=XFiUilcf10d8n4jG3ptTy+000wRbpW9NbybW4RnxH4uKJiBSttKUVfV7Zfs35lRu8x bpC1U9ceOUXk4TNWQaSZjn8pGA7GpCX4530FSUnh+c3obH+YEJ3f611MRMjh17VzI6vf rzLOiXot7SvNLmCwjKksffz5Bz5Ct5j2GuI0zdQvnjlgRZUM/zFviFJHnniq5zse60pI tNG3r1GpQYmW1kGiZkuJBzW3bG4jdU36sOayONhC8Awj5ewHEvch54nlkZAAi4Z/76j7 WEuN8r1XyWx8HZ5Alxi/Cj+SLVx9vczeMjfOPS6cFVucCPjn2OUNXYgvX3dHUuB9Q65m felw== X-Gm-Message-State: AElRT7EkAukiedYye2jnFb5JTQEk4D2IEclFbweaAS9jg3924mQQt+Zg VheObqTEOtvecunZVS1TO2q8ueksKoBcz5TgmOf6DhTY X-Google-Smtp-Source: AG47ELt/A+jjxB8AH4e3esWBHxUV3YnVveAF1Ax9++92g139dgz+KQcJiq6hKn2M+N7nRwJl5KlNLS2gbzPia2Q7oKA= X-Received: by 2002:a9d:24e1:: with SMTP id z88-v6mr18426859ota.116.1521837009310; Fri, 23 Mar 2018 13:30:09 -0700 (PDT) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2364 Archived-At: --00000000000058989305681a4a55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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 th= ere > 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. > > I'm still thinking this over, especially the distribution-specific dependencies. The tl;dr version is, we are really dealing with the intersection of settings specific to the supervisor, the distribution's policy (in the form of naming-by-path, environment settings, file locations, etc), and the options needed for the version of the daemon used. If you can account for all three, you should be able to get consistent run scripts. The launch of a simple longrun process is nearly (but not entirely) universal. What I typically see in > 90% of cases are: 1. designation of the scripting environment in the shebang, to enforce consistency. 2. clearing and resetting the environment state. 3. if needed, capture STDERR for in-line logging. 4. if needed, running any pre-start programs to create conditions (example: uuid generation prior to launching udev) 5. if needed, the creation of a run directory at the distribution-approved location 7. if needed, permission changes to the run directory 6. if needed, ownership changes to the run directory 7. as needed, chain loading helper programs, with dependencies on path 8. as needed, chain loading environment variables 9. specification of the daemon to run, with dependencies on path 10. settings as appropriate for the version of daemon used, with dependencies on path The few processes that can't do this, typically have either a design flaw or a very elaborate launch process. Either of those require a "special" run file anyways, so they are already exceptions. The following issues arise from distribution causing policy to be needed: * The type of logging used, which can vary quite a bit * The various names of the supervisory programs * The path of the daemon itself * The path of the daemon's settings file and/or directory * Naming conventions for devices, especially network devices * How to deal with "instances" of a service * Handling of failures in the finish file * Changes in valid option flags between different versions of a daemon Notice that the first 4 could easily be turned into parameters. Device names I don't have an answer for - yet. Instances are going to be dependent on the supervisor and system-state mechanism used, and frankly, I think are beyond the scope of the project. I don't have an answer for the finish file at this time because that is a behavior dictated by distribution policy; it too is outside of scope. The last one, option flags, can be overcome by making them a parameter. The idea that we could turn the bulk of policy into parametric settings that are isolated away from code is why I have not been as concerned about separation of policy. I've been messing around with using two parametric files + simple macro expansion of the 10 longrun steps listed above to build the run files as needed. You would use it like this: 1. You download the source code. 2. You specify a supervisor in a settings file, which in turn provides all of the correct names for various programs 3. You specify a distribution "environment" in a settings file, which provides path information, device naming, etc. 4. You run a build process to create all of the run files, which incorporate the correct values based on the settings from the prior two files. 5. You run a final build step that installs the files into a "svcdef" directory which contains all of the definitions ready-to-use; this would correspond with the s6 approach of a definition directory that does not contain the active run-time state. (Of course, it doesn't have to be named "svcdef"...) At some point this year, I will turn my attention again to supervision-scripts and scrap the code while keeping the settings, once I find a consistent and non-obscure way to build run files. Hopefully this gives some food for thought, and also some potential answers to "the distribution policy problem" . --00000000000058989305681a4a55--