From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2909 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit SIGPWR support Date: Sat, 29 Feb 2020 13:44:35 +0000 Message-ID: References: <18110531581952419@sas8-7ec005b03c91.qloud-c.yandex.net> <7003111582476686@vla3-6a5326aeb4ee.qloud-c.yandex.net> <77a6d0d5-f292-b225-e9b9-77c290394b47@gmx.com> <20200224152617.GA28493@mail.hallyn.com> <5f5e0473-4ed1-58c0-26af-2eabf43232b0@gmx.com> <20200228063947.w6le5lzy7wbfs4xf@klumpi.ignorelist.com> <20200228094541.GA2429@cube> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="10829"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 To: supervision@list.skarnet.org Original-X-From: supervision-return-2498-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Sat Feb 29 14:44:47 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 1j82QB-0002ZP-Jk for gcsg-supervision@m.gmane-mx.org; Sat, 29 Feb 2020 14:44:47 +0100 Original-Received: (qmail 11503 invoked by uid 89); 29 Feb 2020 13:45:04 -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 11493 invoked from network); 29 Feb 2020 13:45:04 -0000 X-Originating-IP: [86.10.101.211] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=Ucp/tpaN c=1 sm=1 tr=0 a=FQ5CjUvp3JFI4KFGyeqcZw==:117 a=FQ5CjUvp3JFI4KFGyeqcZw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dIZw1YEVAAAA:8 a=Ye9q-bpsAAAA:8 a=xNf9USuDAAAA:8 a=2zQIBqjde0DbSbuCxOoA:9 a=QEXdDO2ut3YA:10 a=GS3RVprl2NcA:10 a=zlcL76zVIypKD7rBcC0t:22 a=SEwjQc04WA-l_NiBhQ7s:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1582983876; bh=lbj/RjQefwQPtPllFcK7BWkoMw/xL9ruJ7kXm4fa3/U=; h=Subject:To:References:From:Date:In-Reply-To; b=d6JghHmpDp9R+NVhJEI+pzKAluh70j8BRLung7DKLpsA03DOdNy0TdYVV5R7n3/jL R+m5LV4BNmECAYsAMf9HVXy5H6/aPIlseu/SbDSrpuZgSXneEHPV3fw7dvkI+Po6S6 LX/kv2nf+8U0OwXGy6u8BiDSI9qPQ14IBGU/oRAMWo5ImOc8xxh0aPgjXTqfh3oiW6 WFOYQkR77fub6vRQTz9k+Agz5a3VabwGEjOQGYyAylCzgKOA9gzlrOnsEvZUdFWz1a oVSwcg4hU3ZE9CFdwTbW0EAX/GD5UvkZJz2Az8/eTIOhNcjRo3UPrtGpnwphko31Qk F3jl1yCMSYKGg== In-Reply-To: <20200228094541.GA2429@cube> X-CMAE-Envelope: MS4wfHW36nzwHxpNE2mkaQebC1MLU7lR0g9OtFDUPkGeoQQdZ2N/duH67PIzj7AEXDiag0tV7Pany5s89lRxdJiMf+Lw8QMdxMpSrUldbCSGD+tL94lPUyGc hh76biY9vHXXc/0KrV2HuD4ngc2KdG6oP0ILQOL33qTShg6HcAwJwaj02ehNEv1gFnMgNWIuoEyfc0WQRLBZeoFoTDXrHtbQ9ptSdYWwKlaryrmlUpYUis3D Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2909 Archived-At: Alex Suykov: > Just for reference, I checked apcupsd sources. > That was not nearly enough research, and your conclusion is ill-founded. The SIGPWR signal, from before Linux even existed, has always meant "something has happened with the power". In AT&T Unix System 5 books it is conventionally described as "power fail/restart". The "something" can include *that the power has been restored*. And indeed, this has been its long-time use, on AT&T Unix and on Linux. Miquel van Smoorenbug's original powerd daemon (which later became Tom Webster's genpowerd), for just one example, sent a SIGPWR to process 1 and beforehand wrote *what that meant* into /etc/powerstatus, which could be "LOW", "FAIL", or "OK". A. B. Prasad's powerh, a trap handler for snmptrapd, did the same. And there are several others over the years. * https://linuxgazette.net/issue83/prasad.html (Indeed, on several operating systems, including HP-UX and SunOS, SIGPWR sent to a process other than process #1 *only* meant "power has been restored", and did not have the power fail meaning at all. Programs were expected to reinitialize after power comes back in their SIGPWR handlers. A full-screen TUI program would re-draw its UI, for example, on the assumption that the local terminals had lost power as well and were currently showing blank screens.) It is quite wrongheaded to think that this can be completely changed into a "shut down and power off" command, for that reason and others besides. Other reasons include that existing systems *already define different signals to mean that*. There is an existing mechanism already. Several, in fact. They need more than one signal, too. systemd (and the nosh toolset's system-manager which has compatible signalling here) uses two of the real-time signals to mean "shut down and power off", one to trigger the service changes, and the other to finalize the procedure. There's no convincing case for either the systemd authors or me to change, given that SIGPWR has already meant something else for a long time and changing it would conflict with existing programs that we want to interoperate with. There's a strongly convincing case to *avoid* changing SIGPWR, in fact. The simple truth is that if you are using SIGPWR to mean only a "power failed" event, you aren't using it correctly. van Smoorenburg init went and looked into /etc/powerstatus and acted accordingly, and still does so *to this day*, albeit that the file is now located under /var/run. (The systemd people and I both provide infrastructure only. We define a target that is activated, but not what services that target invokes; and we leave it up to the third-party services to determine what the power change event actually is.) Send a SIGPWR to process 1 without writing /run/powerstatus means that you'll get the last power change event set by the person that *did* use the signal properly. Moreover, not only is there an existing mechanism in such programs, there are *several* existing mechanisms. And they don't even all use signals. The program being run could be anything, not just system-manager, or runit-init, or systemd, or finit, or even one of the several specialized programs designed solely to be process #1 of a container. *Even just those* do not all use signals. * https://unix.stackexchange.com/a/191875/5132 In the case of van Smoorenburg init and Joachim Nilsson's finit, there is a private API for commanding system state changes, idiosyncratic to just those softwares (and not compatible even across the twain), involving sending messages along a FIFO that process #1 is reading the other end of. Ironically, Karl M. Hegbloom augmented genpowerd back in 1998 to optionally use this API, which is more expansive than the comparatively small signal API that van Smoorenburg init has. To properly use van Smoorenburg init or Nilsson finit in a container, you have to configure the container manager to *do something else instead of sending signals at all* to send it system management commands such as "shut down and halt/restart/poweroff/powercycle", as the API for commanding these is not signals. The right place to handle all of these variances is in the container manager's configuration settings. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=23007#25 If you want to have some sort of "shut down and halt/restart/poweroff/powercycle" API between a container manager and process #1 inside a container, slightly absurd that the idea is for something that isn't a fully-fledged virtual machine with a virtual power supply, it is the program that is run that dictates the protocol to you, *not* you that dictates to the program being run. The correct course of action is to tailor the container manager to the particular program, not try to make all programs, decades after the fact, suddenly discard and incompatibly overwrite the long-established, event not command, meaning of SIGPWR.