Custom plugin that works in Nagios core 3.4 but not 4.0.1

[heebs]

Yes, the CALLATTEMPTS variable was empty from the nagios runs, the output from my second cat, is has the value of 37389 at end of it, I made one run manually to make sure I was not getting the same results on the command line as well, and it came back as I expected.

[sreinhardt]

OK, did you happen to be running as the nagios user or just root when running manually? Is this a second box from the 3.4 machine, such that you might have to give the nagios user some additional permissions for sqlplus? Testing via su-ing to the nagios user and running from the cli just as it worked with root, is probably the next logical step.

[abrist]

Does nagios have rights to 'sqlplus?'. How about:

Code: Select all

/usr/local/nagios/scripts/set_db_name.sh

You could try shifting the echos upward and changing the macro:

Code: Select all

#!/bin/sh

# Gracefully fail if stack number not specified on command line
if [ -z "$1" ]
then
        echo "Usage: sbapp_callattempts.sh <stack_number>"
        exit 3
else
        STACK=$1
fi

DB_NAME=`/usr/local/nagios/scripts/set_db_name.sh $STACK`

echo $DB_NAME > /tmp/call_attempts_test.txt

CALLATTEMPTS=`sqlplus -S nagios_adm/xxxxxx@$DB_NAME << EOF
set head off
set pagesize 0
<some sql stuff here>
/
EOF`

case $CALLATTEMPTS in
'no')
        echo "OK:  CALLATTEMPTS 0 | call_attempts=0"
        exit 0
        ;;
''|*[!0-9]*)
        echo "UNKNOWN: Could not get valid number for call attempts"
        exit 3
        ;;
*)
        echo "OK:  CALLATTEMPTS $CALLATTEMPTS | call_attempts=$CALLATTEMPTS"
        exit 0
;;
esac

[heebs]

OK, did you happen to be running as the nagios user or just root when running manually? Is this a second box from the 3.4 machine, such that you might have to give the nagios user some additional permissions for sqlplus? Testing via su-ing to the nagios user and running from the cli just as it worked with root, is probably the next logical step.

The manual run that I did was done as the nagios user. The post I had a ealier was a run of the script with -x to see the whole deal. This is on the 4.0.1 machine that it is doing this. The same exact script never fails command line or through nagios on the 3.4 machine.

[abrist]

What was the output from the script in my last post? Was DB_NAME populated?

[heebs]

Sorry I was chasing some production death. Here we go:
nagios@monitorbos02|/tmp>tail -f call_attempts_test.txt
SBDB6P
SBDB6P
SBRACP
SB4THP



So it is populating that variable.

[abrist]

Well, the issue has to be in the sql . . .
Or with permissions . . .

Code: Select all

CALLATTEMPTS=`sqlplus -S nagios_adm/xxxxxx@$DB_NAME << EOF
set head off
set pagesize 0
<some sql stuff here>
/
EOF`

[heebs]

I understand that it seems to be that way, but why would I get results on the 3.4 installation, from the command line, but not from the 4.0.1 installation? I spent lots of time looking at this before coming to ask questions because it makes no real sense for it to fail in this fashion. I will gather the same echos on the older installation later on to show that part of the output.

btw, I appreciate the time that has been spent on this.

[heebs]

Ok, so I should have done this before harassing people with it but here is the solution that I was thinking about in the shower this morning while revving up for work and it even worked. It seems that 4.0 isn't loading the full nagios user environment as was done in the past, so I just specifically loaded up the .bash_profile. Anyone else having this type of issue should add this line to their custom sh/bash scripts

Code: Select all

. /home/nagios/.bash_profile

[abrist]

Good catch. The environment configuration is usually done by the user, though a long while ago our installer did set some of it up. Glad it is resolved. Should we lock this thread with impunity?