From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2869 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit SIGPWR support Date: Fri, 14 Feb 2020 18:30:47 +0000 Message-ID: References: <20200131043919.GF12551@cathexis.xen.prgmr.com> <20200214131544.tcvmh7tqu4hu2gul@caspervector> <1f198ed8-3682-26cd-e8d5-2efc412afde2@gmx.com> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="80429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.36908.0 To: innerspacepilot , supervision@list.skarnet.org Original-X-From: supervision-return-2458-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Fri Feb 14 19:30:55 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1j2fjr-000Kj9-Ae for gcsg-supervision@m.gmane-mx.org; Fri, 14 Feb 2020 19:30:55 +0100 Original-Received: (qmail 22301 invoked by uid 89); 14 Feb 2020 18:31:14 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 22294 invoked from network); 14 Feb 2020 18:31:13 -0000 In-Reply-To: <1f198ed8-3682-26cd-e8d5-2efc412afde2@gmx.com> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrjedtgdduudegucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2869 Archived-At: >You mean that adding few lines of code in one place is worse than many >users of many distros must configure their containers? >I can configure that myself, but I don't want every user of runit driven >container to walk this path. Is it necessary? As counterintuitive as it may seem at first glance, the answers to your questions are yes and yes. Patching software is always more complex than configuring it. Configuring software is using an API that has been especially thought out to accommodate the needs of various users; if a piece of software does what you want but requires you to tweak a configuration lever, then it does what you want period. Because your needing to tweak the configuration lever is *the exact reason why that lever is there*. If you refuse to use it, you are basically putting your needs in front of everyone else's, and demanding that the author of the software adapt to you at the exclusion of others, instead of using the mechanism that has been prepared for you. Patching software: - requires communication with upstream, so, takes support resources - requires new deployment, which is significant effort - is dangerous: it may introduce bugs that you haven't thought of - may change the workflow of other users It is, of course, a supplementary order of magnitude more difficult with software that has no well-defined upstream, as is the case with runit these days. But even if your containers were using s6, which has a well-defined upstream (me) and which does not understand SIGPWR either, I would not apply your patch suggestion. Why? Because SIGPWR is not standardized, and s6 aims to be portable, it works ootb on other systems than Linux and making it use SIGPWR would endanger that. It's the exact kind of problems you haven't thought of but run into when you want to patch software, and makes patching always more complex than it seems from the outside. Explaining to users how to configure lxc to send the correct signal to the init system running in the container is a matter of one line in the documentation. It's extremely manageable. >Also there is a huge lack of documentation about it on the net, >especially on signals that runit accepts. You are talking about patching the code, and you're not going to look at runit's code to see what signals it accepts? ;) >It adds complexity to users, and that means users will choose other >distros which just work. If your definition of "just working" is "everything is working with the default configuration", then I don't think you'll find a single Linux distribution that "just works". Your runit distro is working just as well as any other. You just need to set one variable in the lxc configuration. It's certainly not the only variable you need to set; it's certainly not even the only variable you need to set conditionally depending on the guest distro. So, there's really no reason to get hung up on this. >>>Why can't we be just a little bit more friendly to each other? Most participants in this thread would benefit from taking this advice to heart. And in your case, the friendliness will consist in using the configuration levers that were made for you instead of demanding that upstream change its defaults to adapt to you. -- Laurent