Hello Philip, > I'd like to propose that we add a new possible return code to Icinga of -1 > (or some other code), that means, leave the previous status in place and do > nothing (a no-op essentially), and simply reschedule the service as if the > check happened normally. The MTA is willing to invest in my time to develop > this functionality, but we do not want to maintain an internal version of > Icinga in parallel to the main branch.
It is usually the job of the plugin to determine the state of the service. If you want to use the last/current state if it is "unknown" you should use the $LASTSERVICESTATE$ or $...ID$ macro as an attribute to your service. So the plugin can return this state instead of unknown. http://docs.icinga.org/1.7/en/macrolist.html#macrolist-lastservicestate I don't think this needs to be a feature in the core... The intelligence here has to come from the plugin. Also I recommend to use 3 as exit code when the state is "unknown" and not 255. Regards Markus -- Markus Frosch mar...@lazyfrosch.de http://www.lazyfrosch.de ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
