On 02/12/2013 05:24 AM, Páll Guðjón Sigurðsson wrote: > Thanks for the sed Andreas, > > If anyone on the list is interested i compared include.common.h from > nagios-3.4.4 with the documentation at > http://www.nagios.org/developerinfo/externalcommands/ and discovered the > following discrepancies: > > External commands that are documented but not found in the source code: > DISABLE_SERVICE_FLAP_DETECTION
This is in reality 'DISABLE_SVC_FLAP_DETECTION' > RESTART_PROGRAM > SHUTDOWN_PROGRAM > These are 'RESTART_PROCESS' and 'SHUTDOWN_PROCESS', respectively. > > External commands that appear undocumented: > NONE This is an error marker for internal use only and shouldn't be documented at all. > DELAY_HOST_SVC_NOTIFICATIONS This is currently unimplemented. > CANCEL_HOST_DOWNTIME > CANCEL_SVC_DOWNTIME > CANCEL_ACTIVE_HOST_DOWNTIME > CANCEL_PENDING_HOST_DOWNTIME > CANCEL_ACTIVE_SVC_DOWNTIME > CANCEL_PENDING_SVC_DOWNTIME > CANCEL_ACTIVE_HOST_SVC_DOWNTIME > CANCEL_PENDING_HOST_SVC_DOWNTIME These are unimplemented, as documented by comments in include/common.h A command overhaul in time for 4.1 would be a good idea. Using a hash- table to look up the command and its handler would be a very good idea indeed. Then we'd do the "insert to hash-table" thing as add_command(char *name, char *description, int (*handler)(char *cmd, char *args)) or some such and generate the help-list from that, while allowing nebs to access the same command parsing routines as the rest of Nagios. Though to be honest, I'd much rather just extend the query handler thing and let commands take key/value vectors via the socket. That way we can support multiline values properly and get rid of nonsensical attributes. > FLUSH_PENDING_COMMANDS This has no meaning anymore, and if I guess correctly it never had, as it would be impossible to submit a command that flushes all pending commands, as any command one want to flush are either already parsed and processed when we get to this command, or hasn't been picked up by the command queue yet (in Nagios 3 that is; In Nagios 4 it has absolutely zero meaning). I'll remove this. > CHANGE_HOST_NOTIFICATION_TIMEPERIOD This is undocumented for real, although its meaning should be fairly self-explanatory. > DEL_DOWNTIME_BY_HOST_NAME > DEL_DOWNTIME_BY_HOSTGROUP_NAME > DEL_DOWNTIME_BY_START_TIME_COMMENT These are the new 'distributable' downtime delete commands, which I suppose are undocumented. > CUSTOM_COMMAND > This is currently unused, to the best of my knowledge. Its intended use is for eventbroker modules that want to accept external commands. There can't really be any documentation for it, apart from whatever the module itself decides to accept as input. Since the query handler got implemented (which allows for feedback from the targeted handler), this should be considered obsolete. > I totally agree with Andreas, that it would be nice if there was a > handler that could print commands, short description, and in an > utopian world, the documentation would be generated from that so there > is no need to maintain it manually. > Well, it still needs to be maintained manually, since the description and the command template isn't going to write itself. It would just be a lot more up to date if the documentation was kept inline with the code. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null