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

Jason Thorpe <[email protected]> writes:

> There’s a comment in the code that describies it:
>
> +#	doeswork	Returns 0 if the script does work that's needed
> +#			for boot, non-zero otherwise.  Scripts are considered
> +#			to do work if either their rcvar is set to YES or
> +#			if they do not have a defined rcvar.
> +#
>
> So let me explain the reasoning.  If a script defines a controlling rcvar, then that script, by definition, has been requested to do nothing if the rcvar evaluates to NO.  Scripts that do not define an rcvar fall into three categories:
>
> - scripts that always do some sort of work (e.g. mountcritlocal)
> - scripts that make some other determination as to whether or not they should do work (e.g. ccd)
> - the barrier scripts (e.g. LOGIN)

> I guess I can really distill it down to: “A script is considered to do no useful work only if it definitively tells us so.”  And it does so by self-reporting that its rcvar is set to NO.

That seems sound.

> The basic rule for rc.d scripts that work in our system is “use
> rc.subr”.  Any script that does will get a safe default for “does
> useful work”.  Any script that doesn’t probably doesn’t actually work
> properly as it is today.  A main design feture of our rc.d system is
> that scripts that don’t provide an explcit action for one of the
> directives get a widely-cast net of reasonable default behavior (and
> yes, I went back and read Luke’s USENIX paper again to provide maximum
> insurance against violating any religious tenents while working on
> this problem).

That is a rule in NetBSD but I do not expect it is followed by all
scripts installed by pkgsrc.

A different view is that the basic rule is that an rc.d script must
implement start, stop, status, reload, and should check a variable.
rc.subr is certainly a good library to use, and a convention, but it
isn't strictly necessary.


> The one situation where it could fall over is “some random rc.d script
> doesn’t use rc.subr at all”, and this it will not respond to the
> “doeswork” directive.  But even if I invert the sense to a “canskip”
> directive, some random rc.d script that doesn’t use rc.subr at all
> could choose to play Towers of Hanoi rather than exit with an error
> status.

Sure, but we can say that "invoked with a command that isn't understood"
should lead to quick error exit as an implied specification, far more
strongly than we can say that using rc.subr is an implied specification.

There are a lot of packages with scripts and many of them are old.

> I guess my point is the only rule a script has to follow is “use
> rc.subr”, which seems to be an *incredibly* low bar (because if they
> don’t, there’s already a myriad of ways those scripts could fall
> over).  If it follows that one rule, then the only way it gets
> optimized out is if is uses a control variable and that control
> variable contains the value that explcitiy says “yo script, you are to
> do no work”.

I don't see any downside to inverting the test.

>> (Also, it seems obvious that if you commit this, it should default to
>> off at first, except perhaps for particularly slow arches.)
>
> Of course, this has the side-effect of reducing the amount of dog
> food-induced problem finding and is yet another step that people have
> to do in order to make their systems run fast, but ok, sure.

I said "at first".   While every change that's committed is believed to
not cause regressions, it seems best to let the first 20 people opt in
and after it's been a month or so and there are no bugs on the table, it
seems ok to make it default.

Basically I don't think it's ok to push testing onto current-users,
until there's been enough testing that finding a bug would be very
surprising.  In this case, testing is all about environments you haven't
contemplated.