From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/675 Path: main.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: pid of controlled service (was Re: runit-1.2.0 available) Date: Fri, 21 Jan 2005 21:47:36 +0000 Message-ID: <20050121214639.16109.qmail@c3770aa02a166f.315fe32.mid.smarden.org> References: <20050121193424.5788.qmail@9205e057e3be69.315fe32.mid.smarden.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1106343984 31702 80.91.229.6 (21 Jan 2005 21:46:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 Jan 2005 21:46:24 +0000 (UTC) Original-X-From: supervision-return-914-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Jan 21 22:46:18 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1Cs6bi-0005cn-00 for ; Fri, 21 Jan 2005 22:46:18 +0100 Original-Received: (qmail 27747 invoked by uid 76); 21 Jan 2005 21:46:38 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 27742 invoked from network); 21 Jan 2005 21:46:38 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: Xref: main.gmane.org gmane.comp.sysutils.supervision.general:675 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:675 On Fri, Jan 21, 2005 at 04:01:54PM -0500, Charlie Brady wrote: > On Fri, 21 Jan 2005, Gerrit Pape wrote: > > I'm not sure that's a good idea. The pid may change while the external > > program is running, better let the runsv program send the signals to the > > service. > > I don't know how that would be possible if you wanted a custom handler to > do something special and then pass the signal on to the daemon. The custom > handler would have no way of asking the runsv process to deliver the signal, > correct? If the program exits with a return code other than zero, runsv still will be sending the signal. The program cannot adjust which signal, but I think that's what the command given via runsvctrl is for. Regards, Gerrit.