From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2471 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Essex: A simple command line interface for managing s6 services, using the s6 toolset Date: Mon, 28 Jan 2019 10:54:49 +0000 Message-ID: <158d0032-fba1-9a70-056f-546136cd3630@NTLWorld.COM> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BCE505BB9E7406DD8F652468" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="221923"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 To: Supervision Original-X-From: supervision-return-2061-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Jan 28 11:57:00 2019 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.89) (envelope-from ) id 1go4b6-000vUz-7C for gcsg-supervision@m.gmane.org; Mon, 28 Jan 2019 11:57:00 +0100 Original-Received: (qmail 24992 invoked by uid 89); 28 Jan 2019 10:57:18 -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 24985 invoked from network); 28 Jan 2019 10:57:18 -0000 X-Originating-IP: [86.10.101.211] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=OO4JIxSB c=1 sm=1 tr=0 a=FQ5CjUvp3JFI4KFGyeqcZw==:117 a=FQ5CjUvp3JFI4KFGyeqcZw==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=2rVjqWD_AAAA:8 a=xNf9USuDAAAA:8 a=vTr9H3xdAAAA:8 a=lB0TnyVTwmfTwO2JUG8A:9 a=QEXdDO2ut3YA:10 a=3f6-rNZx_yYA:10 a=BZPIIt-EYvcA:10 a=s8LNz1OBhQEA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=dSlVzVPFHV7vs83cdJIA:9 a=FWl-Zuq_O3D6Xq1H:21 a=_W_S_7VecoQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=SEwjQc04WA-l_NiBhQ7s:22 a=7PCjnrUJ-F5voXmZD6jJ:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1548672890; bh=2jL3xjuTl6m467qjEyzSzfRIsAQ6Oq6Esu9RcNTBOaI=; h=Subject:To:References:From:Date:In-Reply-To; b=Tm0pXGiaKSafCtWujHg85oYO5G2EXsI9V76kZAZfQ8hrF8fqC/TbDNsLe9naLEeE5 OvqAts9ERlw2GSH9ob4pVafAdIC4J8yx8IvQqxFWCoajiVjf8c8bwf+2gd30Z+L4jW 0FVA99aQCNKwNpSAco6+EK0J17V4ZByI+kgyGz6yQxFxyp58OYXuO2guGsvUkTdiS+ eBwELHYT16svfi10cyJi1eIM2m5KiAw2/u30QEAMu7AloPR44pTjr9L3wIYzg0FFds 7Dhai8+oLbV98ESg8iD9FX8J4UIOBgBD/p+lIrxdj0dXYd832tApqW2GtS/XqZcjz2 S+kCFal1giV+Q== In-Reply-To: X-CMAE-Envelope: MS4wfI7XUDdN48vYyD5RjvwhXSA912naDd7eC+oS5fZL1VeVV95SfWjZehZFtLDdM9k0H/SUfcw2YN2gEzthX+KWItIlC/Y8iYuYB1Ox23uegz4ER2XSM9HD 0Svw/AQOTsa0RggHo2JWjLe47AlaglmC0j8/yIrVArBEhOpNGulvs3jtKVTRBONgGVFFsujmqw7oNp0UCCqm6OrvwAutQ/MOteRDLVhyMM1EZK3DIDjDVXo2 B9zpXEHBNURNVG7cHOhq9w== Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2471 Archived-At: --------------BCE505BB9E7406DD8F652468 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The |cat| subcommand is the one that seems to get most people. I have seen more objections to that in systemd's |systemctl| than to any of the others, because it really isn't concatenation as people are used to. I provide it in my toolset because I provide migration paths for people familiar with systemd. I would not have chosen |cat| myself, if I had had the choice. (It is actually |grep| under the covers, not |cat|, for starters.) If you are /not/ looking to have similar commands as a systemd migration path, which seems to be the case from the other subcommands that you have, you would probably do well to come up with a better name than |cat|. I went with |reset| rather than |sync|. |preset| sets the /enable/ state from configuration information. |reset| sets the /start/ state from configuration information, and as the manual says can be thought of as "reset to however the service is configured to be at bootstrap" with respect to start/stop. |sync| is not a bad name, but |system-control| can do /system/-level stuff (e.g. |poweroff|) as well as /service/-level stuff, and there is a definite quite different meaning to |sync| when one is operating at system level which would not be a good idea to overlap. You're providing service management and not system management, and contrastingly are probably alright here. Your |reload| is not what people have come to know and to think of by that name, and will probably confuse people. What people have come to know by that name is sending a "reload" signal (of some kind, the exact signal varies) to the service telling the service to /keep running/ but reload stuff. What you have is more akin to what people know as |condrestart| or |try-restart|, although it is not quite those either, because (for one thing) they do not have the side-effect of starting currently stopped services as your |reload| subcommand does. See the Debian /Policy Manual/ and the Fedora wiki for the long standing meanings of the |try-restart| and |reload| subcommands. Placing the generation of the information that your |reload| operates on actually in the |run| script itself is a bit of a layering violation. Really, a framework to detect changes to |run| scripts should have no effect on the |run| scripts contents themselves, certainly not the requirement that they be modified to inject special extra commands. You end up with user problems, with users setting up vanilla |run| scripts that they get from elsewhere and then not being able to successfully employ your tools on top of that. You end up with mechanism problems, with a /single change/ to a |run| script resulting in potentially /repeated/ termination signals (if |reload| is called more than once, which people inevitably /will/ do) until the part of the |run| script that regenerates the signature actually re-runs, and takes. Observe how I designed service bundles. They are layered on top of |supervise/| and |service/| directories. Before/after orderings, wants/conflicts dependencies, and the rest are all /outwith/ the scripts, and do not require modifying them. Only |system-control| has dealings in them. The scripts, the lower-level |service-control| /|svc|, and indeed the |service-manager| itself, have no notion of /any/ of that. Indeed, it is one of /two/ ways of deciding what services to run, the other of which would be adversely affected if all of the scripts had to incorporate tooling for the first mechanism. Maintaining layering allows drop-in replacement, and the administrator a choice of the |system-control| way or a daemontools-style |service-dt-scanner| /|svscan| way. Maintaining layering allows further forms of drop-in replacement, too. My nosh toolset does not require that |run| scripts use the toolset's own chain-loading utilities. It is just as happy with |run| scripts that use execline, or the perp tools, or runit's |chpst|. The service manager only cares that it's a program that it can |fexecve()|. Whereas your tooling forces execline for everything, because you've built it around having a snippet of execline code embedded in an execline script as a part of the mechanism. For a restart-if-the-|run|-script-has-changed framework, I suggest a similar approach. The simplest approach is surely to have a per-service |Makefile.essex|, or a set of redo |.do| scripts, that embodies the if-file-X-changed-take-action-Y logic. That is after all what those tools do. Then it is a matter of running |make -f Makefile.essex restart-if-changed|, or |redo ||restart-if-changed|, against each service. Or (alternatively) make a tool that knows about the extra |.md5| files and like |make| and |redo| does the whole of the job in one place, i.e. put all of the /(re-)generation/ logic into |EssexReload| /as well//as/ the testing logic. Then when you fix it to also take into account changes to environment directories, which it does not at the moment (and so does not really restart /all/ services whose definitions have changed), your users will not have to go and laboriously fix all of their own |run| scripts to include even more extra commands. Rather, your tooling fixes the |Makefile.essex| or the |restart-if-changed.do| file (or the |EssexReload| logic) that /belongs to it/, and the improvements happen as a matter of course. You also should think about what happens if someone makes two services that share a single |service/| directory (but have their own |supervise/| directories), and about whether making all services write to files (with no precautionary checking that they are regular files) before they drop superuser privileges has introduced an exploitable security hole. (One has to at least do the analysis, even if the answer turns out to be no. I've been musing on the idea of a |--write-new| option to |fdredir| for this; although in 601 services as of version 1.39 only two even use it to write, they both write to files in |/run/| where only the superuser could place malicious links anyway, and one of them is obsoleted by the klogd-read service. If the other were to become a problem, giving the dynamic Message Of The Day its own user account, that could only update that one file, would be an alternative solution. Although a better solution yet is /not/ to have this as a service at all, consider it also obsolete, and use |/etc/system-control/convert/motd|. The regeneration point for the Debian-style dynamic Message Of The Day is when a file has changed in |/etc/update-motd.d/| or the operating system has been upgraded, not bootstrap.) --------------BCE505BB9E7406DD8F652468--