Greetings Marc,<div><br></div><div>Well, I've wrapped the command in question with /bin/echo { command_line def. } >> /tmp/check_http_jmx.log to see what Nagios is issuing. </div><div><br></div><div>The -I flag of the check_http command was being issued with just a dollar sign ($) as it's parameter.</div>
<div><br></div><div>So i think it's a matter of macro double spanning, because there is a custom macro ($_HOSTIP_PRIVATE_VIP_1$) being passed to be spanned by $ARG1$ at the command_line definition. I do not know If I ever saw or used a configuration like this. </div>
<div><br></div><div>I don't think is a problem of quoting, because Nagios should replace $_HOSTIP_PRIVATE_VIP_1$ by it's custom host value say, 10.0.0.1, and then pass this value to be replaced at $ARG1$ standard command macro, but all I see is a dolar sign being issued by nagios as a parameter of -I. </div>
<div><br></div><div>Then my second question in my next email about double macro spanning. </div><div><br></div><div>Do you think it could be a configuration problem? </div><div><br></div><div>Best regards,</div><div>Marcel</div>
<div><div><br><div class="gmail_quote">On Tue, Nov 17, 2009 at 4:39 PM, Marc Powell <span dir="ltr"><<a href="mailto:marc@ena.com">marc@ena.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Nov 17, 2009, at 10:45 AM, Marcel wrote:<br>
<br>
> Now I want to refer to this $_HOSTip_provate_VIP_1$ macro in services definitions, but nagios is complaining about not finding the service.<br>
<br>
</div>What is the exact error that you are seeing? I can't see how a problem with that macro substitution would generate any error about 'not finding the service'.<br>
<div class="im"><br>
> The documentation isn't clear whether or not custom macros could be used in service definitions.<br>
><br>
> I've a command like this:<br>
><br>
> define command{<br>
>    command_name   check_http_str_return_args<br>
>    command_line      $USER1$/check_http -I $ARG1$ $ARG2$<br>
>    }<br>
><br>
> And the service definition:<br>
><br>
> define service{<br>
>    use generic-service<br>
>    (...)<br>
>    check_command check_http_str_return_args!$_HOSTip_private_VIP_1$!-u / -t 10 -w 3 -c 5 -e HTTP/1.1 200 OK<br>
>    }<br>
<br>
</div>This is unusual but based on the documentation on how to check service and host clusters, I expect this should probably work. Looking in the code it looks like macro substitution happens at the right place too... There is a problem with the resulting command in that '-e HTTP/1.1 200 OK' will be translated to '-e' with an argument of 'HTTP/1.1' and then a dangling 200 and a dangling OK to the entire command. If you want to match more than HTTP/1.1, enclose the entire 'HTTP/1.1 200 OK' in quotes.<br>

<div class="im"><br>
> My question is:<br>
><br>
> Is it by design that custom macros should NOT be used in service definitions?<br>
<br>
</div>I don't recall seeing it stated either way (should/should not). I know that you can use other macros in this way and don't believe that custom macros are special.<br>
<div><div></div><div class="h5"><br>
--<br>
Marc<br>
<br>
<br>
------------------------------------------------------------------------------<br>
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day<br>
trial. Simplify your report design, integration and deployment - and focus on<br>
what you do best, core application coding. Discover what's new with<br>
Crystal Reports now.  <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a><br>
_______________________________________________<br>
Nagios-users mailing list<br>
<a href="mailto:Nagios-users@lists.sourceforge.net">Nagios-users@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/nagios-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-users</a><br>
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.<br>
::: Messages without supporting info will risk being sent to /dev/null<br>
</div></div></blockquote></div><br></div></div>