From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:54:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DB201065673; Tue, 17 Jan 2012 21:54:07 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 465878FC17; Tue, 17 Jan 2012 21:54:06 +0000 (UTC) Received: by iagz16 with SMTP id z16so8833881iag.13 for ; Tue, 17 Jan 2012 13:54:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.77.234 with SMTP id v10mr7388716igw.29.1326837246518; Tue, 17 Jan 2012 13:54:06 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:54:06 -0800 (PST) In-Reply-To: <86boq2smsv.fsf@ds4.des.no> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <86boq2smsv.fsf@ds4.des.no> Date: Tue, 17 Jan 2012 13:54:06 -0800 Message-ID: From: Jos Backus To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:54:07 -0000 2012/1/17 Dag-Erling Sm=F8rgrav > Jos Backus writes: > > I want/need a solution that works in (nearly) all cases and is devoid o= f > > complex code trying to track state that is already represented elsewher= e > in > > the system (the process table and the parent/child process > > relationship). > > Please show me the complex code required to handle pidfiles. > In my solution, no such code exists, so whatever code is there now (the pidfile library/API) is more complex by definition :) > > > I want a solution that can reliably handle a crashing server that > > doesn't clean up its pidfile > > That's a strawman. Whatever tool you use needs to be able to handle > stale pidfiles anyway. > Um, why? The solution I propose doesn't use pidfiles at all. > > > I want a unified control interface for the services running on a box, > > a la launchd or what have you. > > So extend service(8) to support enabling / disabling services through > /etc/rc.conf.d/. Probably no more than an afternoon's > work. > > > This isn't about religion but about missing base system functionality > > - the ability to reliably control services running on a box. > > The onus is on you to show that we don't already have that. > As I said before, the only thing we have today that will automatically restart services is init, and it is not flexible enough. That's where launchd would come in, but that would be a much more invasive change than just adding the daemontools bits, which would be optional and could be integrated gradually. Jos > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > --=20 Jos Backus jos at catnook.com