On Wed, May 17, 2006 at 03:53:53PM -0700, Richard Elling wrote: > On Wed, 2006-05-17 at 16:48 -0500, Nicolas Williams wrote: > > Or perhaps you could fire off a monitor from the start method of the > > actual service to be monitored using ctrun to run the monitor in its own > > process contract and restartably. This avoids having a separate SMF > > service polluting the SMF service namespace. > > This can get a bit complicated. Suppose FMA kills the monitor > contract and the monitor loses its state of the monitored service. > For simple monitors, such as "does the process exist," this won't > be a problem. For a monitor which is making a database transaction, > then there needs to be enough smarts in the monitor to cancel an > in-flight transactions which might interfere with its analysis of > the database health. It is not clear to me that stateless monitors > will be more useful than the current method, so it might be somewhat > complex to write a good monitor.
I'm not sure what this has to do with either Liane's suggestion or mine. In both approaches the monitor 'method' runs in its own contract and with a restarter. In both cases the monitor can die/be killed and will get restarted, and in both cases the monitor has to know what to do to recover. The question was: how can I build a monitor facility given SMF. Liane provided one answer, and described the long-term direction for SMF in this area. I provided an alternative short-term answer. Perhaps the full-fledged SMF monitor facility can provide additional features that make monitor recovery from monitor restart easier, but I think that's a problem that SMF can't generally solve. > Monitors also tend to have timeouts, which further complicates their > deployment. It is not clear to me that we can avoid following the > current path of cluster monitors, even as they get more complicated > (eg. dynamically adjustable timeouts). It might be better just to > implement a single-node cluster instead, when possible, thus > leveraging the existing agents. See above.
