Idea for FreeBSD

[Vincent Hoffman]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>