From the service check definition. If you re-read the last part of my previous post, the plugin receives its input arguments when nagios runs it - $ARG1$, $ARG2$…$ARGN$ are defined in the command object “command_line” and they map directly to the service object definition variables after each ! delimiter in the “check_command”…
Here it is in colour…
command_line $USER1$/check_foo -I $HOSTADDRESS$ -x $ARG1$ -y $ARG2$…and so on
The exact contents of your “command_line” entry will depend on the information that check_foo needs to operate. This is normally along the lines of a host IP address and one or more arguments. Pretty much all check plugins allow you to ./check_foo --help to assist with identifying the syntax and requirements for said plugin. The $USER1$ macro represents the path to your libexec directory. $HOSTADDRESS$ represent’s the IP address of the host from which the service check is called. These are filled in automagically by nagios.
Once that’s done, you may then use check_foo in your service check object, e.g.
use generic-service ; Inherit default values from a template
Notice the check_command delimiter - ! - this seperates the arguments that are passed to the command object. The variable after the initial ! will map to $ARG1$, the one after the second ! to $ARG2$, and so on. When this check is called, nagios executes the following
/<path_to_libexec>/check_foo -I -x firstarg -y secondarg[/quote]
…of course as always TIMTOWTDI… As a for instance if you had a plugin like check_http or check_snmp with multiple uses you wouldn’t want to go and create lots of different command object definitions for each way you might implement it, so you just have the one and use a singe argument in the command object and a single delimiter followed by multiple argumens in the service object… like if you have check_foo and it can either check for thing1 or thing2 with various ‘thing’ purpose-relevant arguments, you just define check_foo like
command_line $USER1$/check_foo -I $HOSTADDRESS$ $ARG1$
you can then use it in different service objects in different ways… like
check_command check_foo!-x thing1 -y tribbles
check_command check_foo!-x thing2 -z rhubarb
Then, when nagios checks service FOO-thing1 for remotehostA it runs check_foo like this
/<path_to_libexec>/check_foo -I -x thing1 -y tribbles
and for FOO-thing2 for remotehostB it runs check_foo like this
/<path_to_libexec>/check_foo -I -x thing2 -z rhubarb
Hope that’s a bit clearer now.