Date: Tue, 12 Aug 2008 13:29:07 +0100 From: Vincent Hoffman <vince@unsane.co.uk> To: Adrian Penisoara <ady@freebsd.ady.ro> Cc: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org, wbentley@futurecis.com Subject: Re: Idea for FreeBSD Message-ID: <48A18213.3050307@unsane.co.uk> In-Reply-To: <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> References: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Penisoara wrote: > <snip lots cause I'm not really joining in here> > > 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 "<svc>_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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48A18213.3050307>