Hi Shubho, You can't just set a knob to make this happen. However, if you are able to modify the code of the resource monitor, you could execute a call to scha_control with the RESOURCE_DISABLE tag when this case occurs. This will stop the monitor and also stops the resource itself, and persistently disables the resource (same as executing "clrs disable" command). The cluster administrator can re-enable the resource when the problem is fixed.
This scha_control RESOURCE_DISABLE tag is currently used in the ScalDeviceGroup and ScalMountPoint resource monitors, when an unrecoverable error occurs. Usually these resource types have offline-restart dependents, so disabling them takes the dependent offline too. I think this is the sort of thing you're trying to do. This is documented on the scha_control(1HA) or (3HA) man page. --Marty On 10/ 6/09 01:41 PM, Ashutosh Tripathi wrote: > Hi Subhadeep, > > I see. Strange situation indeed, sounds like either a > badly designed probe or a badly behaving app or both. > > The strange part being that starting the application is > always OK, even though SC (rather the Agents built by Agent > builder) typically would probe the app at start time as well > to make sure it really did start. It must be related to load, > as you suggested. > > Badly designed app/probe or not, it would be good to have > a knob in SC which can get you the behavior of getting the > application into an errored/offline state if it keeps failing > after successfully starting. > > I do not believe that today we have such a knob in SC, > but perhaps someone else on the list would prove be happily wrong. > > -ashu > > > Subhadeep Sinha wrote: >> Hey Ashu, >> >> In my case the resource doesn't fail to start ever. The probe fails >> due to some rough weather the application runs into after it is >> started and then SC restarts the resource for retry_count times. It >> is then that the resource enters a faulted/unmonitored state where >> probing is stopped. But the final state of the resource is still >> "online". >> >> Thanks, >> - Shubho. > _______________________________________________ > ha-clusters-discuss mailing list > ha-clusters-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
