Re: rc improvements (wanted?)

From: Doug Barton <dougb_at_FreeBSD.org>
Date: Fri, 18 Jul 2008 22:19:22 -0700
Bernd Walter wrote:
> Speaking about small systems, where startup time is more a problem than
> on 08/15 desktop and server systems.
> What I would love to see is that scripts like moused, ypserv, lpt, etc
> are not started if the services are disabled.

That wold be a neat trick, how do you propose we accomplish it? (no, 
I'm not being snide.)

There are 144 scripts in /etc/rc.d/ on HEAD right now. Out of those I 
count roughly 40 that I actually need, so let's round off to 100 
unnecessary scripts to make the math easy. On my system (a pretty fast 
C2D) it takes roughly .3 seconds of wall clock time to run one script 
that is not enabled. Now cut that roughly in half since each of those 
scripts will not have to suck in /etc/rc.subr and /etc/rc.conf* when 
run at boot time, and that's 15 seconds of boot time that I could save 
on average, let's say +/- 5 seconds. That's worth giving some thought to.

One way you could do this is to have /etc/rc.d/active and 
/etc/rc.d/inactive (and probably an /etc/rc.d/system for critical 
stuff that most people shouldn't touch). Then you could have a 
vipw-like system to allow users to edit rc.conf that would move the 
scripts to the right directory. Of course, this would be fraught with 
potential for problems. :)

Another thing that would work for systems that a more sophisticated 
admin/user updates with mergemaster would be to write a pre-compare 
script that removes all the scripts you know you don't need from the 
temproot/etc/rc.d so that they don't get installed. Of course the 
benefit of that would not be nearly as wide spread, but it would also 
not result in so much foot-shooting.

> So far each script is started, sucks in routines plus rc.conf

We're actually a little smarter than that. :) rc.subr and 
rc.conf[.local] are loaded once by rc, then each script that runs 
inherits those values.

hth,

Doug

-- 

     This .signature sanitized for your protection
Received on Sat Jul 19 2008 - 03:19:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:33 UTC