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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
