From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2875 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: innerspacepilot Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit SIGPWR support Date: Mon, 17 Feb 2020 13:00:12 +0300 Message-ID: References: <20200131043919.GF12551@cathexis.xen.prgmr.com> <20200214131544.tcvmh7tqu4hu2gul@caspervector> <1f198ed8-3682-26cd-e8d5-2efc412afde2@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="24232"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 To: Laurent Bercot , supervision@list.skarnet.org Original-X-From: supervision-return-2464-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Mon Feb 17 11:00:25 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 1j3dCT-00069P-GZ for gcsg-supervision@m.gmane-mx.org; Mon, 17 Feb 2020 11:00:25 +0100 Original-Received: (qmail 2122 invoked by uid 89); 17 Feb 2020 10:00:43 -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 2113 invoked from network); 17 Feb 2020 10:00:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581933614; bh=+rsWt858creT14es7uVGwoIkKPf7HR72icXY2L8hyO0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=iO4DVANY5KJ7+X56NafEn2+T3vgXuw18tkZEI+tHrb1mMEjNjh+BD+rsphBLRlYqo ZT9btTIspfasIO+50e8C2jyqhFEiKDHYQsm7X/KbVe6jyOKlpnt+3gj8MQnieDWZQ4 frzdsDv9elztAmQ9PI7IaOK2WknoxLv9uv4AfdIE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:BJdcM7/WqbfHjyyrEDbAEhzbzQT1VeKvEBBE8sKqP5FIWq8uiOM FRc2uGWXasF8v5DWrwcpf8N1e80v5t4NeDJs0hYzYS3/PF+yosjjbxmyuBJn9MT7LJtQt1M l14ZhGuPupN6YWYiR1bMHbzzzNsrou8/D7LmNKdi4jGLIMLc5NBPLylloWNC2R7is//lRVB 9odLy/e8TNx4oc40bN5rA== X-UI-Out-Filterresults: notjunk:1;V03:K0:qS3s+/5W8Cw=:qgAIdeu1zyfDTjYGIiCAz6 iZwCPuyXPASRkPxZYz6gHAtyU2k3W/rQjeB/0Hm6jHRJrtHmuglQAnDobl7Y7QlLdN8itPtoN ZTEJ+lUihT84IsHfrIxfq77pKIxXPlcMRahyWwcZqJ9sluplD7NmeD9JTfJQ7w64dAOQQ0Dyd 8ZozWoKb2trGPmS079jaVdkRMjLywkC2IpQMYCsyrVKN5Fmx/cgHyLsPvswdYZ/Rij9eNWACp T0rolEnnhTImYxQVIPzcg3gnDmV7crV6HyipNoI16IRyGY6nbYyvGJygBU0xBex33px1YWVti vTetb1NvXNUPcq2YpX8PTAVdjcYH84+ZZyB8LaPak1xQE36UaxW/2v5z0r5uGZzLi/oqy4sAj FfTNRoKYQnpVjR79T7oOe5xHzhS4N0c2c97fv9YKQDGYi0offGoPk+GfBM/F8XBVybQhTwxRM K29iC5Irbdi4k8gv7ULwdI5us8XyEcdzYdEMCCbeMFfW1lb8cg6JKW+JWMASi1o20PABz8Upi A36nRdOcnYzYDk7bNEYXJ5pMrPbYWmQ4fELuSsMbcpoj5CJNKc47nsSt5M29/8J+aUP4CW6Kz zY8nCarIvBG121Uxb9cbiZtW2lO6hg2OY2r8AihMZu7lk/8XmxyWL9khSVQZOJ7+V4vagAceL FH9i02lQQsFvpCJyVVfSdi35u0AVdA28TH38Jw++cy/+D9DdRA8KC8XV839WdzF551Sy004bm UMyy2qqfAJF/xYid+H9cntuQ19P392cVL8c2YIiuFSGx/a95hidy7Vv/pd8wpPN+7Ap4OKfE Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2875 Archived-At: Great, your point I wanted to hear especially. But, well, I am disillusioned with my hops for s6. My fault about SIGPWR, RTMIN+3 should be used instead, please, treat SIGPWR as a template for any other signal name, that doesn't matter. Not only me who want this "lxd simplicity", e.g. https://github.com/skarnet/s6/issues/5, where you fully described your position. Just as a thought: You have implemented signal diversion, but limited to known signals. Why not just pass unknown signals as numbers or something like (S6SIG55011), so they can be diverted by user? You wouldn't have to catalogue them. We need good, flexible and user-friendly init alternatives for linux (other systems have their own). So, I just want to make user experience of new runit or s6 users who use LXD more comfortable, apologies if this hurts someone. Have a good day! On 14.02.2020 21:30, Laurent Bercot wrote: >> 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 drive= n >> 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? > > =C2=A0Most participants in this thread would benefit from taking this ad= vice > 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. > > -- > =C2=A0Laurent >