From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2497 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.comp.sysutils.supervision.general Subject: svscan and supervise Date: Sun, 3 Feb 2019 10:39:40 +0000 Message-ID: <277e527a-912f-d878-fe90-9aec37065b93@NTLWorld.COM> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------583CCC1A894EFD53BB5B4C00" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="32728"; 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-2087-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Feb 03 11:41:43 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 1gqFDb-0008RM-0O for gcsg-supervision@m.gmane.org; Sun, 03 Feb 2019 11:41:43 +0100 Original-Received: (qmail 18467 invoked by uid 89); 3 Feb 2019 10:42:08 -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 18460 invoked from network); 3 Feb 2019 10:42:08 -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=XubUx2N9 c=1 sm=1 tr=0 a=FQ5CjUvp3JFI4KFGyeqcZw==:117 a=FQ5CjUvp3JFI4KFGyeqcZw==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=2rVjqWD_AAAA:8 a=GaAcVgsp1xYMn2F1SF0A:9 a=pILNOxqGKmIA:10 a=It8hHWhJUA4A:10 a=D_5i-koR1_8A:10 a=SGZ2O69BzekA:10 a=pMx8C87NoaAA:10 a=4snO6NFRy5EA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=18M-I2JlVNEJ5O90dPIA:9 a=T4jgT3S7s_-s4RrG:21 a=_W_S_7VecoQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1549190381; bh=V6CtzMhdEZq75KyR/yDdJDAu5Iz+s8Fa+b81q1X/akw=; h=From:Subject:To:References:Date:In-Reply-To; b=Cb5W6moq8I+NpAaX+pebfr/kMekVaA517nWlMjcwgtzwBbtCJZHSglbjwcZTMVMwX WNxx+5o4zm8mrvROYgLa0Yv1lfGnD7GzTyrNwgRaOHHpJUlwGzHI9sqy2vdhM2KOPt ydHJVC2LyfgrxjbvkA9Vjyqi099OUOILWGcjoT9vCT5GNqVEUdLx8tUsNQyQBIDbwx rzHo80+V4pjl5y5bKLdzk6AUmiJaTjXanf7dHLFV+4RgecWqlKXRW4R0SfQPQA0P0T OqafnArvukBzNJhZbe5YAbkfD2IG+VF1dFoPCVRw93fbodeMZ2wGNmAL/hYh90e0rY 72fJMu58x7MwQ== In-Reply-To: X-CMAE-Envelope: MS4wfEqecR1RTXAaaQjRpTjo/ofQ/gQxlqLG9Sz8KL4Y2LKEpppgUzQOh5geo4N+LTEuFaIZ4QZXb7ris6Tsw5qOy6/tDBF9YF6lMcKEBtYWkcutDVCATC4W nEAJXLGsiNoRXCj3uMGq0VigyK9uvuxKfSkGQ1CEUIGbDNReWaJ/9Uo+8jTTcUY+59kPYVV7d9bBnOg3HkpS45+bJhlkBsLBh7k= Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2497 Archived-At: --------------583CCC1A894EFD53BB5B4C00 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Kelly Dean: > Surely this is a common question. > It's a common redesign. In the original daemontools, |supervise| knows nothing at all about the difference between "log" and "main" services. Linking up the standard I/Os with pipes, to connect "main" services to "log" services, and knowing the directory layout that delineates them, is entirely the domain of |svscan|, which in its turn knows nothing at all about the control/status API and about supervision. M. Bercot has stuck with this design. As laid out in this Frequently Given Answer , three of the other toolsets did not, and went down the path of tighter integration of the twain. They baked in a relationship between "main" and "log" services. In the original daemontools design, it was theoretically possible to run |supervise| under something else, that set up different relationships. Indeed, in the original daemontools |svscan| came along (in version 0.60) about two years after |supervise| did, /originally/ in early versions people were expected to run |supervise| directly, and it was more like |daemon| in its operation. This was until it became apparent that "dæmonization" is a fallacy, and simply does not work on modern operating systems where login sessions have gone through too many one-way trapdoors for escaping to a dæmon context to be viable. Running dæmons outwith login session context /right from the top/ became the way, with |svscan| and (the also since much-replaced ) |svscanboot|. This was of course how service management had been done on AIX since 1990 and on AT&T Unix since 1988 . My nosh toolset did not stick with the original design in this regard, either. But I did not go for tighter integration, which I thought to be the wrong thing to do. |service-manager| manages a whole bunch of services, does all of the waiting and spawning in a single process, which is conventionally also a subreaper, and provides all of the control/status APIs. But the knowledge of the relationships amongst those services, and of directory structures, is entirely /outwith/ that program. It is, rather, in programs like |system-control| (in its |start| and |stop| subcommands) and |service-dt-scanner| . They decide the policy, which services' standard I/Os are plumbed together and how a "main" service indicates its "log" service. They instruct |service-manager| with the |service/| and |supervise/| directories, passing it open file descriptors for them, and what to plumb to what, and it just runs the mechanism. They even implement /two different/ policies, one with ordering and dependency processing and a full /service bundle/ mechanism and the other more like the old daemontools and s6 /scan directory/. There is no reason that a third tool could not implement a third policy still. There is not even a requirement of a 1:1 relationship between "main" and "log" services, and indeed the set of pre-supplied service bundles has fan-in arrangements for a few of the short-lived single-shot services that run at bootstrap/shutdown, with them sharing a single logger. The pre-supplied per-user services have three fan-in sets , too. --------------583CCC1A894EFD53BB5B4C00--