From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:54:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30321065670; Sat, 19 Jul 2008 22:54:49 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8C48FC0A; Sat, 19 Jul 2008 22:54:49 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6JMsjg6080066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Jul 2008 00:54:45 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6JMsbJt068315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 00:54:38 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6JMsb2q052750; Sun, 20 Jul 2008 00:54:37 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6JMsaCq052749; Sun, 20 Jul 2008 00:54:36 +0200 (CEST) (envelope-from ticso) Date: Sun, 20 Jul 2008 00:54:36 +0200 From: Bernd Walter To: mouss Message-ID: <20080719225435.GN35340@cicely7.cicely.de> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <48820259.3060007@quip.cz> <20080719153530.GL35340@cicely7.cicely.de> <488230CD.6000906@netoyen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488230CD.6000906@netoyen.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.139, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Doug Barton , David Naylor , ticso@cicely.de, freebsd-current@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:54:49 -0000 On Sat, Jul 19, 2008 at 08:22:05PM +0200, mouss wrote: > Bernd Walter wrote: > >On Sat, Jul 19, 2008 at 05:03:53PM +0200, Miroslav Lachman wrote: > >>Bernd Walter wrote: > >> > >>[...] > >> > >>>Speaking about small systems, where startup time is more a problem than > >>>on 08/15 desktop and server systems. > >>>What I would love to see is that scripts like moused, ypserv, lpt, etc > >>>are not started if the services are disabled. > >>>So far each script is started, sucks in routines plus rc.conf then > >>>possibly does nothing reasonable after wasting some seconds boottime. > >>>Of course I can remove the scripts, but you'll never know if you need > >>>one of them at a later time and having the right set of scripts can > >>>become tricky. > >>And what about just chmod unneeded scripts to become not executable / > >>readable instead of removing? > >>(I like the current "one directory" layout instead of some linuxism with > >>many directories and symlinks) > > > >This and all the ideas about using enable/disable directories or > >softlinks share a major problem: > >They requires configuring outside of rc.conf, which is not what I want. > >Of course I can do: > >mkdir /etc/rc.d/disabled ; mv /etc/rc.d/moused /etc/rc.d/disabled > >But then I would loose the ability to configure everything with rc.conf. > >A tool, which parses rc.conf and automatically relocates might be an > >option, but it would be better if it can be done without. > > > > > how about a cache mechanism: rcorder/rc would use a previously > determined order unless something changed in rc.conf or rc.d. > > this way you don't need to determine which scripts need to run and in > which order every time the system boots. this also removes the need for > an "active.d" directory. Sounds good, but I think the problem is that rc.conf is a script and that some people do smart rc.conf settings e.g. by loader settings to allow their notebooks to boot differently. That of course also invalidaes my idea with the tool above. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.