Executing a script from Nagios event handler fails to run

Question

I have Nagios running on a webserver. For this one Nagios service check in particular, if it fails, it will run a script. This script is triggered via Nagios event handlers.

Nagios event handler command:

define command{
        command_name    testDisableServer
        command_line    /usr/local/nagios/etc/objects/event_handlers/testDisableServer.sh
}

I am executing a script called testDisableServer.sh from Nagios event handlers that looks like this:

#!/bin/bash
wall "Script execution started";
/usr/bin/sudo /root/scripts/disableServer.sh force

This script 'testDisableServer.sh' has the following permissions:

-rwxr-xr-x 1 nagios nagios 2.0K Oct 12 14:57 testDisableServer.sh

When the service goes down, I will get a wall post in my SSH connection saying "Script execution started", but it will not trigger my disableServer.sh script. I tried to place another wall post inside of disableServer.sh and it did not trigger it.

This script is being run by the user 'nagios'. 'nagios' was added in visudo, as such:

nagios  ALL=(ALL)NOPASSWD:/root/scripts/disableServer.sh

Running this script as the user 'nagios' from a command line works perfectly fine. However, when the event handler triggers it, there is no output. I tried to catch the output into a log file, and I came up with nothing. These are the permissions on /root/scripts/disableServer.sh:

-rwxr-xr-x   1 root root 2.0K Oct 12 15:01 disableServer.sh

Why would the event handler hit 'testDisableServer.sh', but not execute 'disableServer.sh' from a Nagios event handler, but work just fine in an SSH connection as the user nagios? BTW, 'testDisableServer.sh' is just an extra layer added to see if the event handlers were working, which they seem to be. This will be removed after this script execution is all sorted out.

Solution 1

Possibly it's an environment issue (the script is relying on something in its environment that is not available when run by nagios).

I would change your script (temporarily for debugging only) to:

#!/bin/bash
exec 2> /tmp/log."$$"
set -x
wall "Script execution started";
/usr/bin/sudo /root/scripts/disableServer.sh force

And add another set -x at the top of disableServer.sh

To see what's going on (in the /tmp/log.* files).

Solution 2

In my case the problem was:

sudo: sorry, you must have a tty to run sudo

So you can just disable it in /etc/sudoers by commenting out

Defaults    requiretty

Which does not have any benefit anyway.

Comments

[Ryan]

You just saved my life. Thank you so much. The log file said this: 'sudo: sorry, you must have a tty to run sudo' So after a quick Google search, I had to comment out this line in sudoers: Defaults requiretty Is there any major security implication for commenting this out that I can't think of off of the top of my head?

[Stéphane Chazelas]

That question has been asked on superuser and serverfault but nobody has come up with a good answer/reason for why that requiretty was added to the default configuration by RedHat. All the reasons I've seen mentionned don't hold up.