From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 23:08:55 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 737721065670; Wed, 8 Feb 2012 23:08:55 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 10D7D8FC1E; Wed, 8 Feb 2012 23:08:55 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 38BA91E1076; Thu, 9 Feb 2012 00:08:53 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 2028D28468; Thu, 9 Feb 2012 00:08:53 +0100 (CET) Date: Thu, 9 Feb 2012 00:08:53 +0100 From: Jilles Tjoelker To: Doug Barton Message-ID: <20120208230852.GA83950@stack.nl> References: <4F322437.5030100@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F322437.5030100@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-rc@FreeBSD.org Subject: Re: Bringing sanity to the RPC/NFS related scripts X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 23:08:55 -0000 On Tue, Feb 07, 2012 at 11:28:55PM -0800, Doug Barton wrote: > Over the years I've been bothered by miscellaneous little "issues" with > the NFS and RPC related scripts, but lately I've seen some real > operational problems that have caused me to poke harder, and I think > I've made some progress. > So first the operational problem. I have a lot of systems for which NFS > is mission-critical, and that includes lockd. However, we're seeing > lockd fail to start because statd didn't start successfully (all the > right knobs are there, but sometimes statd fails for unrelated reasons). > Currently rc.d/lockd has this: > if ! checkyesno rpcbind_enable && \ > ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 > then > force_depend rpcbind || ret=1 > fi > which seems to be going the right direction, but a) doesn't include > statd, That part makes sense. The lockd depends on statd and cannot work without it. > and b) the test for "is it running?" is conditional on it not > being _enable'd, which is counterproductive for a couple of reasons. (I > can elaborate if necessary, but hopefully it's obvious?) So I'd like to > propose removing the _enable check from all the relevant scripts that > have this force_depend capability. For users who already have _enable > for these services it will cause one extra call to forcestatus for them, > but given that rc.d currently has no other way to ensure that required > dependencies are running, I think it's worth it. This was discussed in August 2011 but no patch was committed. See http://lists.freebsd.org/pipermail/freebsd-rc/2011-August/002412.html The existing code makes a lot of sense for the case [ -n "${rc_fast}" ] (avoiding unnecessary slow checks for processes at boot) but may be less convenient for starting such services manually. The patch appears to fix the manual start case without slowing down boot, unlike bluntly removing checkyesno which will slow down boot. > The other thing about the status quo is the fact that statd and lockd > check that either nfs_server or nfs_client is _enable'd before they run > start or stop. This was added almost 5 years ago by mtm, but it creates > a variety of problems, not the least of which is that it prevents users > from using forcestart or onestart to start these services. Worse is the > stop_precmd that also checks these knobs before proceeding. That makes sense. > The attached patch does the following: > 1. Makes force_depend conditional only on the forcestatus checks for the > relevant services, as described above. > 2. Removes the tests for nfs_{client|server}_enable from lockd and > statd, described above. > 3. Adds a check that statd is running to rc.d/lockd > 4. Simplifies/standardizes various elements of the shell syntax. If you're touching the code anyway, it would make sense to change 1>/dev/null to >/dev/null. > Index: mountd > =================================================================== > --- mountd (revision 231185) > +++ mountd (working copy) > [snip] > @@ -49,7 +47,6 @@ > > rm -f /var/db/mountdtab > ( umask 022 ; > /var/db/mountdtab ) > - return 0 > } > > load_rc_config $name Note that this changes the return value of mountd_precmd if /var/db/mountdtab cannot be created. Is this deliberate? -- Jilles Tjoelker