From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2917 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, 16 Mar 2020 18:03:24 +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> <7003111582476686@vla3-6a5326aeb4ee.qloud-c.yandex.net> <3686661584361308@sas2-5ca48d2b4cd3.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="8890"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.37929.0 To: supervision Original-X-From: supervision-return-2506-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Mon Mar 16 19:03:27 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 1jDu5H-00027G-06 for gcsg-supervision@m.gmane-mx.org; Mon, 16 Mar 2020 19:03:27 +0100 Original-Received: (qmail 15724 invoked by uid 89); 16 Mar 2020 18:03:53 -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 15714 invoked from network); 16 Mar 2020 18:03:52 -0000 In-Reply-To: <3686661584361308@sas2-5ca48d2b4cd3.qloud-c.yandex.net> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeffedgleduucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2917 Archived-At: >will the setting achieved by this very ioctl() call survive after >exec()ing into another binary (s6-svscan/stage 2) ? Testing on s6-linux-init 1.0.4.0 shows that a SIGWINCH is sent to s6-svscan on kbrequest after s6-linux-init has performed the ioctl. So, the answer seems to be yes. Having device state changes not survive execve() would be a very unfriendly, un-Unixy design. I don't doubt there are some of those out there, but apparently this isn't one of them. -- Laurent