Date: Mon, 1 Oct 2007 14:13:36 -0700 (PDT) From: Doug Barton <dougb@FreeBSD.org> To: Mike Telahun Makonnen <mmakonnen@gmail.com> Cc: freebsd-rc@freebsd.org Subject: Re: rc.d cleanup patch redux Message-ID: <alpine.BSF.0.9999.0710011407380.39380@ync.qbhto.arg> In-Reply-To: <584bfc3f0709300300s22f2606w3f2628edc1aa15f@mail.gmail.com> References: <alpine.BSF.0.9999.0709221521520.63456@qbhto.arg> <584bfc3f0709300300s22f2606w3f2628edc1aa15f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Sep 2007, Mike Telahun Makonnen wrote:
> On 9/23/07, Doug Barton <dougb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.0.9999.0710011407380.39380>