Complex nagios command

Question

I have defined the following command for one of my service checks:

define command{
        command_name    mycommand
        command_line    $USER1$/check_by_ssh -p $ARG1$ -l nagios -i /etc/nagios2/keys/key1 -H $HOSTADDRESS$ -v -C 'source $USER10$ ; command.py -a get --alert-name $ARG2$ -q'
        }

The problem is that it seems that nagios is parsing the command with the semicolon, and producing garbage which can not be executed. I have tried also putting a backslash \;, to no avail.

If I run the command directly on the shell, it works. Which means that this is not a problem with check_by_ssh, but a problem on the parsing of the nagios configuration file.

How can I debug this? Is there a way to get a listing of all the commands that nagios has parsed when reading the configuration files?

Answer 1

From comments discussion:

Nagios is apparently eating up anything after the semicolon in the "command" definition. The easiest way to manage this is to wrap up the complex command into a shell script that will be called by Nagios.

As part of debugging, the running Nagios configuration can be viewed using the CGI from the web interface, specifically the config.cgi (e.g., https://nagios.example.com/cgi-bin/nagios3/config.cgi). This will show the current set of commands, hosts, etc.

Answer 2

You may not like my answer based on your comment

I have over 100 services, and creating a script for each will not be practical

But I think you should look into using NRPE, the Nagios Remote Plugin Executor.

From their site:

NRPE allows you to remotely execute Nagios plugins on other Linux/Unix machines. This allows you to monitor remote machine metrics (disk usage, CPU load, etc.). NRPE can also communicate with some of the Windows agent addons, so you can execute scripts and check metrics on remote Windows machines as well

I switched to NRPE from a setup similar to yours a while ago, and yes, it was a bit of a pain to install and set up new software on many serves which I wanted to monitor. However the benefit was worth it; it was a much more reliable setup and once set up it's easy to manage the Nagios checks on each server.