From owner-freebsd-ports@FreeBSD.ORG Wed Sep 15 08:04:15 2010 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 747EF10656A8 for ; Wed, 15 Sep 2010 08:04:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 207BF8FC24 for ; Wed, 15 Sep 2010 08:04:14 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id 6w4F1f0041swQuc55w4F8w; Wed, 15 Sep 2010 08:04:15 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.westchester.pa.mail.comcast.net with comcast id 6w4D1f0063LrwQ23bw4EWE; Wed, 15 Sep 2010 08:04:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 79DD69B423; Wed, 15 Sep 2010 01:04:12 -0700 (PDT) Date: Wed, 15 Sep 2010 01:04:12 -0700 From: Jeremy Chadwick To: perryh@pluto.rain.com Message-ID: <20100915080412.GA54898@icarus.home.lan> References: <20100911222902.bb57444a.nork@FreeBSD.org> <20100911173359.68d71af6@it.buh.tecnik93.com> <4C901FD0.5000304@FreeBSD.org> <4c90738f.W4uzxD1k7guRTp+n%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c90738f.W4uzxD1k7guRTp+n%perryh@pluto.rain.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ports@freebsd.org, swhetzel@gmail.com, itetcu@freebsd.org, dougb@freebsd.org, nork@freebsd.org Subject: Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 08:04:15 -0000 On Wed, Sep 15, 2010 at 12:19:43AM -0700, perryh@pluto.rain.com wrote: > Doug Barton wrote: > > > >>> ... Is it really absolutely necessary > > >>> to stop a service before it's files go away? > > > > IMO the only time the ports infrastructure itself should do this > > is if it isn't possible to pkg_delete the port cleanly if it's > > running. For example, if there is a file being held open that > > cannot be deleted unless the service is stopped ... > > Which should be an exceedingly rare circumstance, since the fact > of some process(es) having a file open will not ordinarily prevent > the removal of any or all directory entries pointing to it. The > inode and disk space won't actually be released until the last > such process closes the file, but another file could be created > having the same pathname as the one whose prior directory entry > was removed. ...which also makes the assumption the daemon doesn't do stat(2) or similar to verify a file exists, or does a multitude of other things that might act on a filesystem but not an open descriptor. We can sit here discussing what a daemon might do or not do until we're blue in the face, which is why I tend to side with Doug's argument that these sorts of tasks (stopping daemons, starting daemons, etc.) should be left to the administrator. I sympathise with the OP, but as I stated previously: what kind of administrator upgrades software, especially a daemon, then doesn't test/check to make sure everything's running correctly after the upgrade? I would rather we not try to solve a borderline social problem with software. But, also like Doug, I see the validity in the need for an automated upgrade infrastructure/framework that can provide daemon auto-stop and auto-start (I strongly oppose the latter) if desired. I just don't know how feasible that is, or if it's worth the time. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |