Nagios Support Forum

Hello everybody.

I am running Nagios XI 2014R2.0.

I have the following command definition:

$USER1$/check_procs --user=nagios -C nsca -w 76 -c 97 $ARG1$ $_HOSTCOUNT_NSCA_PROCS_OVERRIDE$

If I use it in a service definition and don’t define anything for $ARG1$, the command is run with $ARG1$ removed from the executed string. However if the host doesn't have the custom variable _count_nsca_procs_override defined, it looks like the macro placeholder $_HOSTCOUNT_NSCA_PROCS_OVERRIDE$ is left exactly as is and is executed. This results in the shell replacing $_HOSTCOUNT_NSCA_PROCS_OVERRIDE with nothing (we don’t export vars at the moment) but it leaves the trailing '$' on the command line to confuse the poor check command 8-(.

So I guess my questions are:

Is this expected?

Why isn’t the custom host macro treated the same as $ARGn$ macros. I can’t imagine that leaving the placeholder there is useful and the variable
placeholders are unique enough $_(HOST|SERVICE|...)[A-z_]+$ that they are very unlikely to match any real value on the command line.

Is there any way to have a macro expansion with a default value when the macro doesn’t exist. E.g. in the shell you can do ${variable:-default}
that is replaced by the default value if variable isn’t defined. I could easily see:
$_HOSTSOMECUSTOMVAR:-A default value if the custom \$ var isn’t defined$
as a suitable syntax.

In my original command definition, I can replace $_HOSTCOUNT_NSCA_PROCS_OVERRIDE$ with $_HOSTCOUNT_NSCA_PROCS_OVERRIDE and send the custom vars to the environment. This will use the shell to do what I want, but it is suboptimal since I have different layers replacing macros and IIRC there are performance considerations with the variables being exported to the environment.

Other suggestion on how to handle this so I can define a single command and allow overriding of the parameters at the service and host level?

Thanks.

This is due to how core handles macros. Built in macros are treated as empty strings until populated by a directive. Custom macros must be declared and populated though, or else nagios will attempt to just interpret the variable name through the shell. It cannot consider all $-wrapped strings as a macro, otherwise it would interfere with potential shell commands a user could potentially try to run from the command directive. So if you are going to use a custom macro, it must be configured, otherwise core will try to interpret it through the shell.

Abrist said:

> It cannot consider all $-wrapped strings as a macro, otherwise it
> would interfere with potential shell commands a user could potentially try to run from the command directive.

I agree replacing all $ wrapped strings would be silly. But the form of the custom macros is very unique.
Custom object macros have the form:

$_(HOST|SERVICE|CONTACT)[A-Z_]+$

I claim that is sufficiently unique to not cause a conflict. Shell variables are unlikely to have a trailing $, so I don’t expect there to be a conflict with the shell vars. In the obscure case where there may be a conflict, ${varname} expands the variable in the shell while preventing expansion by the Nagios macro processor. E.G. ${_HOSTSOMEMACRONAME}$ will not be expandable by the Nagios macro expander (as ${ does not match $_), but will be expanded by the shell.

I actually agree with you, though I guess that was not part of the original vision of how macro processing was handled. This may be a good feature nonetheless, though it may take some time for it to get traction. You ca make a feature request here:
http://tracker.nagios.org