From owner-freebsd-rc@FreeBSD.ORG Mon Oct 1 21:13:41 2007 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E132016A41B for ; Mon, 1 Oct 2007 21:13:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id AE33A13C467 for ; Mon, 1 Oct 2007 21:13:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 7275 invoked by uid 399); 1 Oct 2007 21:13:39 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 1 Oct 2007 21:13:39 -0000 X-Originating-IP: 127.0.0.1 Date: Mon, 1 Oct 2007 14:13:36 -0700 (PDT) From: Doug Barton To: Mike Telahun Makonnen In-Reply-To: <584bfc3f0709300300s22f2606w3f2628edc1aa15f@mail.gmail.com> Message-ID: References: <584bfc3f0709300300s22f2606w3f2628edc1aa15f@mail.gmail.com> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-rc@freebsd.org Subject: Re: rc.d cleanup patch redux X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:13:42 -0000 On Sun, 30 Sep 2007, Mike Telahun Makonnen wrote: > On 9/23/07, Doug Barton 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