From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 398 invoked from network); 23 Oct 2020 00:03:31 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2020 00:03:31 -0000 Received: (qmail 21780 invoked by uid 89); 23 Oct 2020 00:03:48 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 21773 invoked from network); 23 Oct 2020 00:03:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; s=default; d=troubleshooters.com; b=JogTnmB0csHBh0LH/XIJErc0PQYnf6iQKnl/ycX11XkKgnZdGYGzreh3TVQ0/TpbIMGvoxeN+XnQsstF4lOBP3vb6Ukl/WdQaQJsQznw0w1Tz8T9DWdggye28TgWcKELCMB2VeCjFL+leTCfWEmAtswU9kd1GxExOHSNLRj4FX0=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1603411398; bh=saxpJg+7IWtDgJByK2OhP4O6QiU=; l=2156; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=K81sldX5Fg4UV4NXxG0CRq2g/QGY8cxaZHyUW2uSlgKkL43Kmaf957c3aUtBbk4ww GwKn5X5O+NqOKQW6cGmn6jSV3caGeTQXzRjdWcRHmjw5fgbAfnbd9Y7CZXVQHR4vj/ /pwoi6hSKmo+2jEW9+8RyIwsidFQN62opS8uXUvU= X-Originating-IP: [184.90.157.212] Date: Thu, 22 Oct 2020 20:03:17 -0400 From: Steve Litt To: supervision@list.skarnet.org Subject: Re: External health Check Process Message-ID: <20201022200317.52224023@mydesk.domain.cxm> In-Reply-To: References: <20201022142829.788f4da5@flunder> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 22 Oct 2020 15:34:37 +0000 "Laurent Bercot" wrote: > Hi Oliver, > > The s6-idiomatic way of doing it would be, as you say, to have a > separate service that calls an external command (the health checker, > which is daemon-specific) with a timeout and watches the exit code. > It is trivial to do in shell, which is why I haven't written any > particular binary for that. > > I could add a program that does it for you so you don't have to > write a 3-line shell script, and a command that creates a s6 service > directory (or even a s6-rc source definition directory) that watches > another service using the aforementioned program, it would not be > hard. However, I am concerned about scope creep, and a common > criticism I hear from distros is that s6 is "too big" - which is > unfair considering that integrated init systems providing the same > level of functionality are 5x-10x bigger, but is really a way of > saying that there are a lot of exposed binaries with miscellaneous > functionality and it's difficult to wrap one's head around it. Laurent, I agree with you. My main attraction to daemontools, runit and s6 is they're simple and understandable. There's almost nothing I can't do with them if I get creative with shellscripts. I understand you insistence on PID1 supervising the real supervisor: That's worth the added complexity. I understand your desire to order process instantiation at boot and to intermix run-once and long-run processes, think that's worth the added complexity, and in fact this is one of the few things I missed in daemontools and runit. But most of the other suggestions that in my opinion are just answers to systemd weenie's "but s6 doesn't have _____" arguments, and don't add nearly enough functionality or convenience for the complexity, or just plain size added to the user manual, to justify. The OP already stated there's a way to do it currently. Why complexify s6 to do something already doable? SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive