Date: Sun, 13 Mar 2011 00:14:01 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r219578 - head/etc Message-ID: <4D7C7CC9.7010901@FreeBSD.org> In-Reply-To: <20110312230830.GA269@stack.nl> References: <201103122113.p2CLD8LO030205@svn.freebsd.org> <20110312230830.GA269@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/12/2011 15:08, Jilles Tjoelker wrote: > On Sat, Mar 12, 2011 at 09:13:08PM +0000, Doug Barton wrote: >> Author: dougb >> Date: Sat Mar 12 21:13:08 2011 >> New Revision: 219578 >> URL: http://svn.freebsd.org/changeset/base/219578 > >> Log: >> Use the allexport option in load_rc_config() in order to avoid having >> to repeatedly read the conf files. Depending on what is enabled the >> files are being read anywhere from 15, 30, or more times currently. >> By loading the values in the environment this is reduced to 1, with >> perhaps a couple more, again depending on what is enabled. > > I wonder if it is a good idea to pollute the environment of many daemons > with this. Although sshd and cron clean it up, there is at least one > daemon that passes the environment on. One of those is devd. I think the argument could be made that this is bad behavior on their part, but if it turns out that it starts affecting things negatively we can take another look at it. > While that > saves four /etc/rc.conf reads on my minimalistic 9-current VM, it > implies that devd must be restarted to pick up changes to /etc/rc.conf. > That seems a POLA violation. I'm not sure what you mean by this. We've always required services to be restarted to pick up rc.conf changes. > With the old code, my VM reads rc.conf nine times at boot. One of them > is the initial load, four of them are via devd and the other four are > because rc.d scripts call each other via execve(2) instead of via the > run_rc_script function. The run_rc_script issue is one that should be looked at regardless, you're right. The four that come out of devd are likely instances of things being started via /etc/rc.d in devd.conf. > The latter four can be avoided but the other > five seem unavoidable. > > I found this by adding the following line to /etc/rc.conf: > echo "rc.conf is being read at $(date) by $(ps -p $$ -o pid= -o ppid= -o args=)">/dev/console Yeah, I put something similar in rc.subr, so I think our results are likely equivalent. > (The new code reads rc.conf once.) > >> The speed-up for boot and shutdown is negligible when rc.conf is >> on local disk, noticable when accessing files over NFS, and dramatic >> when pulling rc.conf values from a database. > >> This change also includes a minor optimization to the conditional >> for $_rc_conf_loaded. > > I don't know if we ever supported 'set -u' in rc.d scripts, Not TMK, but I have no plans to MFC this right away, so I'm happy to revisit it if it causes problems. Thanks! Doug > but this > definitely breaks it. To fix this, test "${_rc_conf_loaded-}" instead of > "$_rc_conf_loaded" > >> Modified: >> head/etc/rc.subr >> >> Modified: head/etc/rc.subr >> ============================================================================== >> --- head/etc/rc.subr Sat Mar 12 20:36:52 2011 (r219577) >> +++ head/etc/rc.subr Sat Mar 12 21:13:08 2011 (r219578) >> @@ -998,9 +998,8 @@ load_rc_config() >> err 3 'USAGE: load_rc_config name' >> fi >> >> - if ${_rc_conf_loaded:-false}; then >> - : >> - else >> + if [ -z "$_rc_conf_loaded" ]; then >> + set -o allexport >> if [ -r /etc/defaults/rc.conf ]; then >> debug "Sourcing /etc/defaults/rc.conf" >> . /etc/defaults/rc.conf >> @@ -1010,6 +1009,7 @@ load_rc_config() >> . /etc/rc.conf >> fi >> _rc_conf_loaded=true >> + set +o allexport >> fi >> if [ -f /etc/rc.conf.d/"$_name" ]; then >> debug "Sourcing /etc/rc.conf.d/${_name}" > -- 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?4D7C7CC9.7010901>