1 of 1 people found this helpful
PATROL Native Recovery Actions run one at a time for each cycle that the parameter remains in ALARM. If your first recovery action or some other condition corrects the problem and clears the ALARM, none of the subsequent Recovery Actions will fire. If you have more than one Recovery Action, the first one will fire when the ALARM occurs and “after N occurrences” is reached. If the parameter remains in ALARM, the second Recovery Action will fire on the next update, then the third, and forth, and so on until all Recovery Actions have been exhausted. If your parameter meets the conditions mentioned here and your second Recovery Action is not firing, then it’s not working correctly and you may need to open a case with BMC technical support.
You can quickly test this by setting the parameter in rapid succession to a value that crosses the ALARM threshold, and then repeat for as many times as it takes to test your conditions (execution of Recovery Actions is not based on polling cycle, it’s based on setting the parameter value). Try putting a print statement in each recovery action so you can verify whether it’s firing.
I hope this helps.
Garland, Now the planets have aligned. I most likely knew that a few years ago.
I know why the second one never fired and that is because I am trying to run two recovery actions on the LOG KM.
But I have the parameter reset if the condition does not occur in the next cycle. So unless the log entry occurs but the next cycle the alert clears and no second recovery action.
Looks like I need to build one recovery action with logic to handle two different needs.
Sounds like you’ve got a plan…