From owner-freebsd-rc@FreeBSD.ORG Tue Aug 12 12:29:23 2008 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 96BA91065670; Tue, 12 Aug 2008 12:29:23 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id F00D68FC17; Tue, 12 Aug 2008 12:29:22 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman-macbook.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m7CCTCEX001748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 13:29:13 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <48A18213.3050307@unsane.co.uk> Date: Tue, 12 Aug 2008 13:29:07 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Adrian Penisoara References: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> In-Reply-To: <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org, wbentley@futurecis.com Subject: Re: Idea for FreeBSD 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: Tue, 12 Aug 2008 12:29:23 -0000 Adrian Penisoara wrote: > > > I also agree that it would be good for the rc.d scripts to > (re)configure themselves, since they are the ones who really know > what's best for them. > > While we're at it, I wish we could leverage the posibility for the > admin to manually start the service at the CLI, no matter whether the > service has been enabled or not -- that is the "_enable" keyword > should have effect only in the bootup/automatic contexts. > > /etc/rc.d/$service forcestart seems to be what you want. I do like the idea of being able to enable/disable services from the rc scripts as /etc/rc.d/$service rcvar | sed 's/NO/YES/' >> /etc/rc.conf and/or editing rc.conf can feel a little clunky at times. Vince >> I think a drop-in command like "rcadm" (someone mentioned this as an idea, >> but cant remember who) would be a good start for managing the states of >> services. Mike Meyer also brought up many good points that I agree with. >> Please try not to get caught up in the XML stuff, that is not a >> requirement or suggestion, it is just an example of how Sun did it, now >> how FreeBSD has to;) >> >> Someone recommended Puppet, but this is an entire framework that would >> have to be added/implemented and configured to work with FreeBSD as well >> as learning a new markup language for it. launchd has a lot of good ideas, >> but I am not sure how mature it is yet; maybe it is a good place to start. >> > > Let's put another name on the table: Upstart (upstart.ubuntu.com). > It's quite fast. > > >> If we start with the basics and break it down and program this from a >> modular standpoint it is not so bad. Begin with the basic (high-level) >> approach. A shell script (service) that is aware of where rc scripts are >> located and that can keep track of what the current state of the services >> (PID's) are. An enable/disable command is nothing more that throwing a >> start/stop command to these rc files. The rc.conf can assist with knowing >> what should be enabled/disabled and what flags to throw at it. For >> EXAMPLE!!!!, (you got that, example only) Solaris uses one master service >> that is started first, and the whole point of that first service is to >> monitor the other services and know what state they are in and starts >> dependent services upon boot. Consider it the service manager almost. >> > > That would very important to for service crash recovery, to keep > critical services running. > > Side note:what about starting up and monitoring services in jails, > probably we'd need one such master service per jail ? > > My 5cents, > Adrian. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >