From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2886 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit SIGPWR support Date: Sun, 23 Feb 2020 17:51:26 +0100 Message-ID: <7003111582476686@vla3-6a5326aeb4ee.qloud-c.yandex.net> References: <20200131043919.GF12551@cathexis.xen.prgmr.com> <20200214131544.tcvmh7tqu4hu2gul@caspervector> <1f198ed8-3682-26cd-e8d5-2efc412afde2@gmx.com> <18110531581952419@sas8-7ec005b03c91.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="49598"; mail-complaints-to="usenet@ciao.gmane.io" To: supervision Original-X-From: supervision-return-2475-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Sun Feb 23 17:51:30 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 1j5uTZ-000CmI-Mo for gcsg-supervision@m.gmane-mx.org; Sun, 23 Feb 2020 17:51:29 +0100 Original-Received: (qmail 29607 invoked by uid 89); 23 Feb 2020 16:51:55 -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 29600 invoked from network); 23 Feb 2020 16:51:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1582476686; bh=jxQtA9xrapY4jxIdczNtpeYFEe1MiziyJE++amC1yCg=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=SPN1xfbgDdsZXm2Dckqhch71WLUFInXp66qFiHzCd4F41G3fBVetNYmBU3F0ptNkE IMJH1qDjDsPbHfpUcrUrzAFElBPwOs7kOosMfKLq7G+DLs9aBzZdF4h2MQ3Q0n/fuM jgnmqYvFJruF7vETrrIHeKR6ix1CSn+8r5k5QJ14= Authentication-Results: mxback7q.mail.yandex.net; dkim=pass header.i=@yandex.com In-Reply-To: X-Mailer: Yamail [ http://yandex.ru ] 5.0 Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2886 Archived-At: 18.02.2020, 10:39, "Laurent Bercot" : > An additional reason is that signaling init is not a casual operation; > instead it's part of a very limited API between the kernel and user > space, to be used in very controlled, exhaustively listed, situations. right. > Now, *as a separate conversation*, you can say that s6-svscan should > be able to handle every signal that the kernel can throw at it, no > matter how unportable. And it is a reasonable request: there are good > arguments for it. indeed. > In the latter case, the kernel takes precedence over init, the kernel > decides what the API is and init must adapt. If the kernel says "when > I get a power failure, I send you SIGPWR", init cannot say "uh, no, > I wish you'd send SIGUSR2 instead". Shut up and handle SIGPWR. right. > In the former case, lxd *emulates* a kernel, and is supposed to adapt > to every kind of init that runs in a container, so it should follow > existing conventions and be able to adapt to every init. And that's > exactly why the lxc.signal.stop configuration switch exists! really ? a process #1 in a namespace is not the "real" process #1, hence there is no requirement to use a "real" init program here. instead it is required to react to all signals lxd may sent if said process #1 was spawned by it. of course things would be easier for everybody if lxd could follow exsiting conventions on the linux platform, i cannot see why it does not use TERM, USR1/2 and so on instead to notify the process #1 it started. but it has no obligation to do so. i guess the only case with a special meaning for SIGPWR is when the real kernel notifies the real process #1 of a power shortage. hence lxd is free to abuse this signal for its own purposes. but this default choice looks indeed quite strange. > systemd, always being a special snowflake, uses SIGRTMIN+3 > and SIGRTMIN+4, because any other choice made way too much sense. why should it not use the RT sigs for this ? this is absolutely ok as linux provides them anyway (unlike OpenBSD). > None of them uses SIGPWR, and for a good reason: SIGPWR does not mean > "the admin requested a system shutdown", it means "power failure". And > it is very possible that the action implemented by the system in case > of a power failure is very different from a shutdown: it could be a > suspend-to-disk, for instance (which is faster than a full shutdown, and > when the power fails you want to save your data *fast*). So, even for > inits that actually understand SIGPWR - and most of them actually do - > SIGPWR is a *terrible* default choice of signal to send as a shutdown > request. It already has a use, and the use is not a normal shutdown. right, agreed. > Arguably, lxc.signal.halt should *always* be set to something else, be > it SIGTERM, SIGUSR1, SIGUSR2, or even lolSIGRTMIN+3. would have been a more obvious choice indeed, but they decided against and this is also ok since this is not the kernel. > So, if you're asking me to implement SIGPWR support in s6 because that's > what lxd sends by default to signal a container shutdown, I will laugh > at you, because you are being, uh, "ridicolous". not really, catch it and let the user handle it, that way s6-svscan could be used as process #1 in an LXC process namespace without problems. > On the other hand, if > you're telling me that s6-svscan needs to understand SIGPWR in case the > kernel wants to signal a power failure, you actually have a good point, > and yes, I should implement SIGPWR support when this signal exists. right, it should be caught anyway and the user should decide via a hook executable what to do about it (see if power returns after a while, sync and suspend to disk if not naturally come to mind here). s6 should also catch SIGWINCH (keyboard request) and let the user handle it via a hook executable if the signal exists btw. dunno if it already does so. you are absolutely right that one should not abuse SIGPWR to signal poweroff to the "real" process #1 started by the kernel, there exist enough other signals for that purpose.