To do some of the hierarchal start/stop at runtime stuff, you really need
a stateful rc system that stores its start/stop state in /var/run/rc.d or
the like. In this way, the system could track various activities and know
which dependencies were already started. However, this has a number of
limitations, including differentiating the start/stop status of the daemon
vs. its script, behavior in an environment under development, etc.
Transarc's AFS product has a notion of a "boss server" that starts and
stops services associated with AFS. It has the added benefit of detecting
service failures, logging them, and performing specified restart behavior
(such as: oh, it failed. log that. try starting it. oh, it failed
again, and within five minutes, so send a louder log message. Damn, it
failed again! And within five minutes! Screw that, page the admin and
stop trying). A powerful tool, although a lot more complex, and maps
poorly into the breadth of services (and their management models) that we
ship.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Thu, 14 Jun 2001, Robert Withrow wrote:
>
> [EMAIL PROTECTED] said:
> :- oops, rc2 isn't started. too bad.
>
> I think that is exactly the desired design. The
> RC *system* starts things correctly, but the manager,
> *bypassing* the RC *system* can start and stop things
> exactly as he wished. For debugging or whatever.
>
> I'd argue that if you want to start/stop a *subtree*, you
> should ask the RC *system* to do that somehow.
>
> --
> Robert Withrow -- (+1 978 288 8256, ESN 248)
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
