Date: Wed, 15 Sep 2010 01:04:12 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: perryh@pluto.rain.com 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 Message-ID: <20100915080412.GA54898@icarus.home.lan> In-Reply-To: <4c90738f.W4uzxD1k7guRTp%2Bn%perryh@pluto.rain.com> References: <20100911222902.bb57444a.nork@FreeBSD.org> <20100911173359.68d71af6@it.buh.tecnik93.com> <AANLkTin0D13%2B9JQJ6wVD7_48Es6rvUJtu=rAx6M1xdjx@mail.gmail.com> <4C901FD0.5000304@FreeBSD.org> <4c90738f.W4uzxD1k7guRTp%2Bn%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 15, 2010 at 12:19:43AM -0700, perryh@pluto.rain.com wrote: > Doug Barton <dougb@freebsd.org> 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100915080412.GA54898>