From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2508 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Generic interrupt command? Date: Sun, 10 Feb 2019 11:41:19 +0000 Message-ID: References: <20190201213620.68abc837@mydesk.domain.cxm> <20190202143014.77a5ac5f@mydesk.domain.cxm> <20190202210810.qckhzw4zgfxui6u3@cathexis.xen.prgmr.com> <20190202164042.20551e42@mydesk.domain.cxm> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="171890"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.33939.0 To: "supervision@list.skarnet.org" Original-X-From: supervision-return-2098-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Feb 10 12:41:21 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gsnU9-000icz-6m for gcsg-supervision@m.gmane.org; Sun, 10 Feb 2019 12:41:21 +0100 Original-Received: (qmail 1770 invoked by uid 89); 10 Feb 2019 11:41:46 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1763 invoked from network); 10 Feb 2019 11:41:46 -0000 In-Reply-To: X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtledrleeigdefudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucfrrghrrghmpehmohguvgepshhmthhpohhuthenucevlhhushhtvghrufhiiigvpedt Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2508 Archived-At: >That's a tough call. On the one hand, it makes simple constructs safer.=20 >On the other, it adds complexity to interpreting the data=20 >programmatically ( the test / [ program errors for integer comparisons=20 >with text, and using scanf() to pull in the values for libc style=20 >programs wouldn't be so simple anymore). That was my thought process originally, but if it makes it riskier or more annoying for programs to use the result of s6-svstat, especially in scripts which are its likely users, I'm willing to change that. >Also, while thinking about this, I wonder the risk of signaling the=20 >wrong program. When svc does it via supervise, it can know the right=20 >program gets the signal because it handles the cleaning of the child=20 >PID. In a script, there is a chance the child has exited and been=20 >replaced between the time the PID was queried by svstat and the time=20 >the kill command gets executed. I don't know how likely a new program=20 >might get the old PID in that time, this receiving the signal intended=20 >for the original child. Well that is one of the reasons for using a supervisor in the first place. Only the parent of a process can reliably send signals to it. Any time you're trying to signal a program and you're not a parent, you are subject to that risk condition. The only 100% safe way is using s6-svc, there's no changing that. So far the only real need to customize a signal has been for the signal that brings a service down, which is now achieved via ./down-signal. I haven't been told of any real use case where sending a non-supported signal, without intending to terminate the service, was necessary. -- Laurent