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 6584 invoked from network); 23 Oct 2020 09:15:30 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2020 09:15:30 -0000 Received: (qmail 28247 invoked by uid 89); 23 Oct 2020 09:15:51 -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 28240 invoked from network); 23 Oct 2020 09:15:50 -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=nbn2RJZKeu04DVuSXRYnDV5IKCqI8CerxsEUk0cVvZ+Xvhe1b2NQ4S0asmjyTXrZMFKO8oGQHrkZ0EJOYsBU4bFDLbpQJteVxZnDJTmn40gH3sIv/PAAbCKr4mkh4oWzOs7+P9EwzpSSsq3iGs3I+Gk76L6HDIlgWY2m0H7R+hk=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1603444523; bh=5GjA7ykIdw/Mjldn/m1GCqGyikc=; l=3410; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=an6MPgxP3faK2RQH97NFYtVDfSoJcMSfgxfzm12JDcY+x37N1mEBetJ3KD0k55wQ3 4YqfcHJDKLdnuXs7Q+TpR9UthAy+fXfUOYNDzW0ku5q9klF+FAv7zvqwC0I9w+gy9W lSAqfckvZL8yCZkTuHleQWS060G6B5X9rldcl2u0= X-Originating-IP: [184.90.157.212] Date: Fri, 23 Oct 2020 05:15:22 -0400 From: Steve Litt To: supervision@list.skarnet.org Subject: Re: External health Check Process Message-ID: <20201023051522.0bf7ca03@mydesk.domain.cxm> In-Reply-To: <20201023092753.517078df@flunder> References: <20201022142829.788f4da5@flunder> <20201022200317.52224023@mydesk.domain.cxm> <20201023092753.517078df@flunder> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 23 Oct 2020 09:27:53 +0200 Oliver Schad wrote: > On Thu, 22 Oct 2020 20:03:17 -0400 > Steve Litt wrote: > > > 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? > > I just miss the elegance of the solution: I get that. But there's a pretty significant cost. Every new feature added to a piece of software makes it harder to understand, creates new nooks and crannies for bugs to hide out in, and increases the number of interactions very significantly. To see interactions at their worst, see my systemd cartoon: http://troubleshooters.com/linux/systemd/lol_systemd.htm I'm not saying s6 is anywhere near that yet. But in my opinion, every feature complexifies the software even more than the last one, and every feature should be evaluated similar to a new purchase of a possession: 1) Where am I going to keep it? How much will it clutter the house? 2) What will I not buy to free up money to buy this thing. > I personally want to model > one service with one s6 service. I'm not sure what you mean by "model". I thought this was about checking the health of each service. Anyway, I understand that you personally want to match the healthchecks one to one with the services, and that would be nice, but not if it adds complexity. [snip the rest of the email, which I didn't understand at all] I'm on probably 25 software mailing lists, and have this discussion on every one of them. Somebody wants some feature. I write back that you can already do that by doing . They write back saying my idea is a kludge. I write back and say I like a nice, simple program that can be written and maintained by one person, features tend to wreck that, all sorts of people want their pet features, and those features are usually unimportant (for instance, way to do it with existing software) to the suggester and *absolutely* unimportant to everyone else. Features clutter up software, and should be done only if they're very important to a large swath of users. With healthchecks, it would be trivial for you to create a shellscript called healthcheck in every service directory that required a healthcheck, then have a program that loops around all the service directories, runs the healthcheck shellscript, and if unhealthy, performs actions listed in the healthcheck subscript. If you do this for awhile, you'll slowly evolve the thing into a more and more convenient form, until others use it. I mean, you'd need to roll it into a tarball and write a bit of documentation, but nothing like changing the whole program. The real beauty of this approach is that, as more and more people use your system and more and more people contribute feedback, sooner or later it reaches a state where it would be much easier to add it as a feature of the whole program, with an interface people like. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive