Date: Sat, 23 Apr 2011 10:13:02 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: rc@freebsd.org Subject: Re: rc scripts change for review Message-ID: <4DB3089E.3070304@FreeBSD.org> In-Reply-To: <295158163.384370.1303347263226.JavaMail.root@erie.cs.uoguelph.ca> References: <295158163.384370.1303347263226.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/20/2011 17:54, Rick Macklem wrote: > Hi, > > I've attached modified versions of mountd and nfsd for /etc/rc.d, plus a > new one called nfssrv. These assume that the mountd and nfsd executables > have a new option "-o" which forces use of the old nfs server and that the > new nfs server is the default. Overall the diffs (http://people.freebsd.org/~rmacklem/rc.conf) seem Ok, but see below about nfssrv. > I also need to add: > oldnfs_server_enable="NO" > to /etc/defaults/rc.conf > - is there a preferred place for this? Near the other nfs related stuff. Please don't forget share/man/man5/rc.conf.5 as well. > 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 And finally a meta-note, I admire that you are at least checking for success on your commands, but FYI rather than relying on return it's helpful to use either warn for advisories or err for fatal errors to provide more information about why things are failing. You can read up on these in the comments in /etc/rc.subr, and/or look in /etc/rc.d for examples of how they are used. hth, 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DB3089E.3070304>