From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1492 Path: news.gmane.org!not-for-mail From: "George Georgalis" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit not collecting zombies Date: Sun, 15 Jul 2007 22:24:05 -0400 Message-ID: <20070716022405.GV3925@run.galis.org> References: <20070620165736.GC12963@home.power> <20070620183532.4571.qmail@9f638fd8b69905.315fe32.mid.smarden.org> <20070623044205.GA1594@home.power> <20070626095920.6195.qmail@3e147d410b1c2c.315fe32.mid.smarden.org> <20070715144704.GS23517@home.power> <20070715190757.GW23517@home.power> <20070715201846.GT3925@run.galis.org> <20070715223553.GU3925@run.galis.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1184552654 21053 80.91.229.12 (16 Jul 2007 02:24:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2007 02:24:14 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-1729-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Jul 16 04:24:12 2007 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1IAGFq-0006gg-Qd for gcsg-supervision@gmane.org; Mon, 16 Jul 2007 04:24:06 +0200 Original-Received: (qmail 24301 invoked by uid 76); 16 Jul 2007 02:24:28 -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 24296 invoked from network); 16 Jul 2007 02:24:28 -0000 Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1492 Archived-At: On Sun, Jul 15, 2007 at 07:06:18PM -0400, Paul Jarc wrote: >"George Georgalis" wrote: >> but in practice isn't the best way to deal with defunct entries by >> attaching fd to a file or socket then exec the child (which may >> fork) so the parent no longer has a fd open to the child? > >It sounds like you're thinking of something like fghack, but that's a >solution to a different problem: a service that forks itself into the >background, which makes it difficult to supervise. The problem here >is different: some processes outlive their parents, so they are >adopted by process 1, but process 1 is not wait()ing for them. I've never tried fghack, nor had problems with defunct supervised processes (nor pid 1 adoptions). what I have seen is emacs sessions run in screen (for weeks at a time) which invoke an interactive R process which fork non interactive R pid that do heavy lifting and eventually stdout to the R process that forked them. *sigh* that approach to invocation creates a defunct R process for every heavy lifting R process that completes. on the other hand the interactive R is able to (invoke within emacs tools/env) aggregate output and do post processing when the child completes with stdout. I've never heard of adoption when child outlives parent. // George -- George Georgalis, information systems scientist <