From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 19 16:48:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 055C0106566C; Tue, 19 Jun 2012 16:48:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6E3C214D8D4; Tue, 19 Jun 2012 16:48:23 +0000 (UTC) Message-ID: <4FE0AD56.8050604@FreeBSD.org> Date: Tue, 19 Jun 2012 09:48:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Wojciech Puchar References: <20120615124849.GI96212@ass.kameli.org> <20120618081140.GK96212@ass.kameli.org> <4FDF6177.5050608@unsane.co.uk> <4FDF6586.9060501@gentoo.org> <4FDFB166.2040709@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Richard Yao , Vincent Hoffman , Nathan Whitehorn , Outback Dingo , openrc@gentoo.org, =?ISO-8859-1?Q?Atte_Peltom=E4ki?= Subject: Re: Replacing rc(8) (Was: FreeBSD Boot Times) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:48:24 -0000 On 6/18/2012 9:39 PM, Wojciech Puchar wrote: >> The latter item is the only place where making changes to rc.d is going >> to help, and only then by parellelizing, and even then you are not >> really going to gain much since most things at boot time are serial. > > grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. In the ports' scripts we tend to be more forgiving, but I've worked with several maintainers to apply more effective solutions where there is a good reason to wait for a dependent service to actually be running. This also brings up a good point, any new rc-alike solution we consider must have support for scripts in ports that is at least as robust as what we have now. Doug -- This .signature sanitized for your protection