Re: Improving the performance of system boot by eliding unused rc.d scripts and caching the result

> On Aug 18, 2026, at 12:07 PM, Robert Elz <[email protected]> wrote:
> 
>    Date:        Mon, 17 Aug 2026 21:46:53 -0700
>    From:        Jason Thorpe <[email protected]>
>    Message-ID:  <[email protected]>
> 
>  | The proposed changes, here: 
>  |	https://www.netbsd.org/~thorpej/rcorder-cache-diff-v2.txt
> 
> One obvious trivial change, in rc.subr:_rc_order_cache_is_valid()
> the test
> 
> 	if [ -f /etc/rcorder.cache ] && ...
> 
> should clearly be using -s instead of -f ... there's no point wasting
> time checking mod times on everything if the later "Verify there is at
> least one valid file..." is guaranteed to fail because the cache (while
> existing) is empty.

Does -s also ensure that it’s a regular file?

> Second, the uses of $f throughout that function should be quoted.   It might
> not seem like it should be needed, but it is

Why is that?  I’ll note that similar sorts of usage in /etc/rc is not quoted (look for ${rcd} and $_rc_elem).  Am I missing something?  (I am not a shell wizard, so..)

> More importantly, nothing there (I can see) is checking that the
> rc.d/* files themselves have not been changed, just that the directory
> hasn't.   Using a sub-standard editor to change the files might change
> the directory as a side effect of updating a file in it, but something
> simple like cp new-rc-file /etc/rc.d/script will not (assuming the script
> existed already) and nor would editing the file with a good editor.

The assumption I was making is that copying over the top of an existing rc.d script will not radically change its behavior vis a vis useful-work.  However, adding or removing a script will obviously update the directory mtime.  I guess the real question is: how much does checking every rc.d script’s mtime negate the performance gain?  I’ll have to run some additional experiments, I suppose.

> If the change to the file were, for example, to alter the default setting
> of the rcvar (so instead of requiring rcvar=YES in rc.conf to enable the
> script, it now requires rcvar=NO in rc.conf (or defaults) to disable it),
> then if done using "cp" or a good editor, would totally break the proposed
> scheme.   That kind of change is perhaps unlikely in NetBSD standard rc.d
> scripts, but is entirely possible in pkgsrc supplied scripts, which generally
> do not go about altering /etc/defaults/rc.conf to modify the default yes/no
> state, it is in the script itself.

In my experience, the pkgsrc-sourced scripts often also ship with an /etc/rc.conf.d/ file that contains defaults that can be edited by the user.

> The script needs to check every single rc.d script to see if it has been
> modified, and at the very least, include that file in the list to be
> evaluated (which would not be trivial to do alone, and put it in the
> correct location in the sequence with the current scheme, so probably
> any single changed file needs to mean to rebuild the cache).

Ah, yes, good point .. the PROVIDE / REQUIRE list for a given script could change.

> Of course test's -nt operator only compares modified times (and there's
> nothing which checks the st_ctime values currently in test(1), it would
> need a new operator (operators probably) or use of "stat(1)" (which can't
> be done at boot time, as it is /usr/bin/stat) to check the better time
> field (none of the rc.d scripts or dirs will normally have either st_mtime or
> st_ctime altered, so testing ctime rather than mtime, were a test available,
> would not make a practical difference, except in the odd case that ctime
> does get altered, but mtime doesn't ... the converse never happens.)
> (This one though is the more minor of the fixes needed.)

Yes, a test for ctime would probably be better.. and I would happily use it if it were available.

> All the other uses of "echo" should be "command echo" instead, to avoid
> using the echo() function defined in rc.subr which deals with ensuring
> partial output lines to the console are properly formatted (not needed
> when the echo is just writing to a file, or to the output of a command
> substitution.)

Ah, yes, I completely forgot about this little quirk.

> They should really be using printf instead of echo (avoid issues with
> script names starting with a '-' or containing \ chars for example) but
> that would still want "command printf" to avoid getting rc.subr()'s 
> printf() function, which exists for the same reason as its echo().

Oh, is printf(1) a shell built-in these days?  No problem, I can do that.  I blame muscle memory.

-- thorpej