From owner-freebsd-rc@FreeBSD.ORG Sun Apr 24 04:43:56 2011 Return-Path: Delivered-To: rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C7A3B1065673 for ; Sun, 24 Apr 2011 04:43:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8761B14F42E; Sun, 24 Apr 2011 04:43:56 +0000 (UTC) Message-ID: <4DB3AA8C.7090003@FreeBSD.org> Date: Sat, 23 Apr 2011 21:43:56 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Rick Macklem References: <1308036720.478939.1303598424273.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1308036720.478939.1303598424273.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rc@freebsd.org Subject: Re: rc scripts change for review 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: Sun, 24 Apr 2011 04:43:56 -0000 On 04/23/2011 15:40, Rick Macklem wrote: >> >>> One thing I am not sure about is the REQUIRE: list in mountd. >>> nfsserver and nfssrv essentially load the respective module. They >>> are only >>> used if sysctl variables need to be set and that's actually done by >>> nfsd. >>> (Should they be listed in mountd or nfsd or ???) >> >> It's not a good idea to add single scripts that only have a tiny >> function, especially if they are only called conditionally (I.e., they >> contain KEYWORD: nostart). It's preferred to handle these things >> things >> in the script that needs them, or if it's necessary in more than one >> script to add a function to the appropriate .subr (rc, or network). >> >> So can you say a little more about what you're trying to accomplish? >> It's not clear to me why instead of doing this: >> >> + if ! sysctl vfs.newnfs>/dev/null 2>&1; then >> + force_depend nfssrv || return 1 >> + fi >> >> you would not just do this: >> >> + if ! sysctl vfs.newnfs>/dev/null 2>&1; then >> + load_kld nfsd >> + fi >> > Well, the intent of the above was to get the module loaded so that > sysctl could manipulate its sysctl variables. I played with it a bit > and it turns out that neither of the above code snippets work in the > sense that they don't affect the outcome. > > What is needed to make the sysctls work is "nfssrv" has to be in the > REQUIRED: list for either mountd or nfsd. Without it, the sysctls fail > with unknown oid. (I'm guessing there is some delay between the load_kld > and when the module gets its sysctl variables registered?) > > Now, I'm not sure whether there is any advantage to specifying "nfssrv" > in nfsd or mountd, although both seem to work when I test them. "nfsserver" > is in mountd, so unless you guys have a better suggestion, that's where > I'll leave it. From what you're describing the reason it works by using the nfsserver and nfssrv scripts is simply an accident of timing. That's not a good thing no matter how you look at it. :) I understand your dilemma in that the nfsserver "solution" was pre-existing, so you were just following the example you had. However I have this odd idea that we ought to fix broken code, not perpetuate it. Even if I weren't interested in this for pedantic value, the fact that it's only working now as an accident of timing is a good reason to fix it. The load_kld module is safe to run unconditionally (it will simply return if the module is loaded). So what you could do (for both cases) is something like this: load_kld nfsd while ! sysctl vfs.newnfs >/dev/null 2>&1; do sleep .5 done If that works, I think we should add that feature to load_kld itself. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/