rc.d cleanup patch redux

[Doug Barton]

On Sun, 30 Sep 2007, Mike Telahun Makonnen wrote:

> On 9/23/07, Doug Barton <dougb at freebsd.org> wrote:
>>
>> 1. Remove "Deprecated variable name support" from rc.subr that was
>> supposed to be done after 6.x branched, but didn't get done (substantially
>> my fault).
>>
>> 2. Remove $NetBSD$ tags from all the rc.d files, since they aren't really
>> relevant any longer, and the information will be in CVS anyway. I'm
>> leaving it in rc.subr since we still occasionally pull stuff over in that
>> file.
>>
>> 3. Remove the comment from named_flags, to match all the other empty
>> _flags variables *grumble*
>
> I don't understand what the purpose of all those empty foo_flags=""
> variables is.

I put in a commented out example for named so that users would know that 
it's a knob which is available for them to twiddle.

> Maybe for 8-CURRENT we can get rid of them from etc/defaults/rc.conf?

Personally I'd rather comment them out, but I'm open to suggestions.

>> 4. s/bootparams/bootparamd/g to match the convention of having $name,
>> PROVIDE, and file name match. I did check to make sure this script isn't
>> called from anywhere else, but if anyone is actually using it that would
>> be great feedback.
>>
>
> Sounds good. Although for 8-CURRENT we might want to go through all the
> other scripts that don't follow this convention and fix thouse up as well (the
> rpc* daemons come to mind).

Yeah, bootparams was just low-hanging fruit.

>> 5. Add the shutdown KEYWORD to all the scripts that start persistent
>> services. I'm not sure why this was never done in the past, but I think it
>> should be done, since it allows the possibility of a clean(er) shutdown. I
>> left out network, routing, and kerberos stuff from this pass, since I
>> don't use kerberos and I'm not sure what effect this would have, and
>> routing (including firewall stuff) can go down last as it does now.
>>
>
> I'm not sure about the usefullness of these. If all the daemon needs is
> a simple kill -TERM, then I believe init already takes care of this. A script
> should make use of the shutdown keyword only if it needs to do additional
> processing. For example, rc.d/amd doesn't do anything special on
> shutdown. It just lets rc.subr(8) glue send a -TERM signal. The only
> benefit I see to adding the shutdown keyword to these kinds of scripts
> is that the shutdown occurs in reverse order of startup (as opposed to
> init just killing them off all at once after rc.shutdown).

Yeah, that's the main benefit I had in mind. I also have a sort of gut 
feeling that doing this would be a good practice to adopt, and can lead to 
other benefits down the road, but I could be wrong.

Any other opinions?

> This change only adds aditional processing during shutdown without any
> real benefit.

I don't see any measurable increase in processing time, but my laptop is 
still on the fastish side.

> Also, rc.d/apm doesn't start any persistent daemons. It simply enables
> and disables the apm funtions. So, I don't think it needs to be run at
> shutdown time.

Yep, good point, I'll take that one out.

Doug

-- 

     This .signature sanitized for your protection