From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2889 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: Mon, 24 Feb 2020 00:33:34 +0000 Message-ID: References: <20200131043919.GF12551@cathexis.xen.prgmr.com> <20200214131544.tcvmh7tqu4hu2gul@caspervector> <1f198ed8-3682-26cd-e8d5-2efc412afde2@gmx.com> <18110531581952419@sas8-7ec005b03c91.qloud-c.yandex.net> <6637411582479111@sas8-ed615920eca2.qloud-c.yandex.net> 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="84751"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.36908.0 To: superstition Original-X-From: supervision-return-2478-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Mon Feb 24 01:33:42 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 1j61gq-000Lry-JU for gcsg-supervision@m.gmane-mx.org; Mon, 24 Feb 2020 01:33:40 +0100 Original-Received: (qmail 6713 invoked by uid 89); 24 Feb 2020 00:34:01 -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 6704 invoked from network); 24 Feb 2020 00:34:00 -0000 In-Reply-To: <6637411582479111@sas8-ed615920eca2.qloud-c.yandex.net> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrkeelgddvgecutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2889 Archived-At: >have you ever used s6 as process #1 on any other platform than Linux ? >i bet you have not even tried to do so on any of the BSDs. The BSDs are a different kind of beast: they're much more tightly integrated than your run-of-the-mill Linux distro, and you can't easily switch out one of the components of a BSD distro. Replacing a BSD's init is absolutely doable: it just requires knowing exactly what sequence of BSD-specific system calls is needed to achieve a correct boot, and perform those in a s6-$os-init sequence, either in stage 1 or stage 2. The problem is that it's not supposed to be a stable API, so the BSDs are free to change it and the work would need to be done again. I don't think that it's worth prioritizing until there is real traction for s6 which means a chance to get the change upstreamed - and even then, because for many reasons, most of them good, the BSDs are extremely reluctant to change if it comes from an outsider. Until it can be upstreamed, bsd-with-s6-as-pid-1 can't be anything more than a fun hack. Some people have toyed with it in the #s6 channel though. Also, s6 works fine on the BSDs as a simple supervisor that doesn't substitute itself to init, so you can already have its advantages without the drawbacks. You can even have a strong supervision guarantee if you use /etc/gettys to start the supervision tree. >so why are you sticking to all this "POSIX-correctness" ? >adding a few lines of code to support a specific platform (linux or any ot= her >unix) looks not like a big problem to me. >sticking to POSIX features in the default case is a good way to >achieve portability, that's right. >but avoiding platform specific advantages at all costs seems >pretty strange to me. I value reproducible behaviour very much. When software behaves differently depending on the platform is run on, it can quickly become a maintenance nightmare. So unless a nonportable feature is *vital* to get correct behaviour, I'd rather not use it. For the SIGPWR and SIGWINCH thing, I made an exception because 1. correctness is more important than anything else and 2. the patch was absolutely trivial, so the increase in complexity due to having architecture-dependent code paths was extremely minor. But the cost needs to be evaluated on a case-by-case basis. Note that I'm not avoiding platform-specific advantages when they can achieve the same functionality. For instance, skalibs declares a getpeereid() function, which isn't standardized in POSIX. The BSDs all provide that function in their libc, so skalibs defers to the direct libc implementation. Linux does not provide it, but has the SO_PEERCRED option to getsockopt() that provides equivalent functionality. Solaris doesn't have either of those things, but it has a getpeerucred() function, which once again allows for some getpeereid() implementation. >solaris, AIX and even OS X are all POSIX platforms, hence it >would be interesting to see if s6 will work out of the box there >(as process #1; handling SIGPWR may be a requirement here). >i am sure it will since unlike systemd it is portable. You are making a disingenuous argument. /sbin/init, aka the first process that is launched by the kernel at boot time, is inherently non-portable, because the exact API between the kernel and init has not been standardized and every system does it differently. However, once the non-portable sequence has been run, there's nothing that prevents s6 from being able to run as process 1. The separation between /sbin/init and cruising phase pid 1 is the very reason for the existence of s6-linux-init (which does the nonportable things for Linux, then execs into the portable s6-svscan), and the package is named s6-linux-init because it is implied that there could easily be s6-freebsd-init, s6-openbsd-init, s6-solaris-init, s6-macos-init and others in the same vein if someone wanted to write them. Again, I have not prioritized this work, but that doesn't mean it's impossible, or even difficult. It just has low value at the moment. The point is that the s6 package, implementing the supervision mechanism, should remain portable, because there's no reason at all it should be OS-dependent. All the nonportable details have been confined to the s6-$os-init package. >those platforms cannot be "POSIX-correct" if not. >hence their kernels should be made "POSIX-correct" to run the >"POSIX-correct" s6 unchanged as process #1. > >so who has to adapt, s6 or those kernels ? *You* have to adapt. You need to stop making false dichotomies and fallacious arguments, because they don't work here. :P -- Laurent