From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 7 07:18:23 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F16A1065671 for ; Thu, 7 Aug 2008 07:18:23 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from istc.kiev.ua (wolf.istc.kiev.ua [193.108.236.1]) by mx1.freebsd.org (Postfix) with ESMTP id DB8438FC1C for ; Thu, 7 Aug 2008 07:18:22 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from [91.123.146.100] (helo=ravenloft.kiev.ua) by istc.kiev.ua with esmtp (Exim 4.52) id 1KQym7-0001n9-8l; Thu, 07 Aug 2008 09:15:05 +0300 Date: Thu, 7 Aug 2008 09:15:00 +0300 From: Alex Kozlov To: hackers@freebsd.org, Michael B Allen , Mike Meyer , spam@rm-rf.kiev.ua Message-ID: <20080807061500.GA23109@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Spam-Report: Content analysis detailz: (0.0 points, 10.0 required) Cc: Subject: Re: Idea for FreeBSD 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, 07 Aug 2008 07:18:23 -0000 On Thu, Aug 07, 2008 at 01:06:38AM -0400, Mike Meyer wrote: >On Wed, 6 Aug 2008 22:34:51 "Michael B Allen" wrote: > > But of course the format of data in a database is largely irrelevant. > > You could implement the same thing with dbm files or a more forgiving > > text format. > > Right. For that matter, you could leave the data in shell scripts, and > build a layer of meta information and tools to manipulate these things > - which is similar to what I see in Linux distros. > > The Solaris smf tools provide some nice facilities: one is single > interface to start, stop, check and restart all the services on a > system. We pretty much have that, as they all use the same basic > arguments to their rc scripts. The only issue is figuring out which > directory to find the rc script in. I use for this simple script [1] plus some programmable completion. > > The other is a single interface to enable, disable and query the > status of all the services. All we really have is the last one: you > can run the script with the rcvar argument, and it'll list the > appropriate variable if it's set, and the value it's set > to. Maybe. Not all of them support this yet. > > As for getting rid of rc.d scripts, yes they're decrepit and I would > > love to see them go but they're simple and third party software may > > depend on them being the norm. Can You please be more elaborate? Yes, rc.d scripts have some problems, but I don't think We need to get rid of them. [1]: $cat /usr/local/bin/service #!/bin/sh name=$1 cmd=$2 . /etc/rc.subr if [ -z "${name}" -o -z "${cmd}" ] then echo ${0##*/} service_name command exit 3 fi if [ -r "/etc/rc.d/${name}" ] then run_rc_script "/etc/rc.d/${name}" ${cmd} exit 0 fi if [ -r "/usr/local/etc/rc.d/${name}" ] then run_rc_script "/usr/local/etc/rc.d/${name}" ${cmd} exit 0 fi if [ -r "/usr/local/etc/rc.d/${name}.sh" ] then run_rc_script "/usr/local/etc/rc.d/${name}.sh" ${cmd} exit 0 fi echo "service '${name}' not found" exit 2 -- Adios