From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 21 22:49:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A4211065672 for ; Thu, 21 Jun 2012 22:49:33 +0000 (UTC) (envelope-from atte.peltomaki@iki.fi) Received: from kameli.org (kameli.org [83.150.86.93]) by mx1.freebsd.org (Postfix) with ESMTP id DD0D58FC0A for ; Thu, 21 Jun 2012 22:49:32 +0000 (UTC) Received: by kameli.org (Postfix, from userid 1001) id 4AC1D11F81E; Fri, 22 Jun 2012 01:49:24 +0300 (EEST) Date: Fri, 22 Jun 2012 01:49:24 +0300 From: Atte =?iso-8859-1?Q?Peltom=E4ki?= To: freebsd-hackers@freebsd.org Message-ID: <20120621224924.GM96212@ass.kameli.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 21 Jun 2012 22:49:33 -0000 On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote: > There's no need to do a wholesale replacement of the RC system in > FreeBSD to support this concept. What you are describing are "service > profiles". And we already have a single file that describes the > default "service profile" for FreeBSD: /etc/rc.conf. That lists > every service that should be started (or stopped). > > All that's missing is a way to tell the RC system to use a different > rc.conf file (like rc.conf.mobile, or rc.conf.wireless or > rc.conf.whatever), and to run through the RC setup based on that file. > > Our current RC system does everything needed except: > - parallel execution of items that don't depend on each other > - monitor running services and restart them if they crash - Service dependencies: if a service fails that is required by another service, the other is stopped as well. - Monitoring services and ability to configure the service supervisor behaviour: if service fails and is restarted X times in period Y, execute action Z. - Extending the concept of service beyond userland. Kernel services are services too, if eg. network is down, you probably don't want to even try to start a dozen jails. - Permission control (like possible in jails now, "limited root"), non-root users can be delegated permissions to start/stop selected services and configure their behaviour. It's clearly arguable as to which of these features and to what extent is reasonable to implement and whether or not it can or should be done in the existing rc system, instead of implementing a new one that just supports the old rc system as it is. There are real benefits in some of these features, but they can easily turn out as esoteric features in a bloated piece of code, if not implemented with great care. I don't know the internals of current rc system well enough to form educated opinion on how any of this could be done in practice, but I have plentyful experience in how and why projects fail and in this particular case I see a lot of chances for fail with relatively little gain. Just something to think about.. Might be worth noting that I work with Linux systems most of the time and over-engineering is a chronic problem there. I've always admired the simple but effective BSD approach, rather do less but well than a lot badly. -- Atte Peltomäki atte.peltomaki@iki.fi <> http://kameli.org "Your effort to remain what you are is what limits you"