notice: embedded perl, getopts and emtpy string in ARGV
Trask
trasko at gmail.com
Thu Apr 13 22:02:03 CEST 2006
This took me so long to figure out, I figured I would share just in
case someone else hits upon this problem one day in the future...
I had an eventhandler that was not working -- It was getting called by
nagios, but it wasn't actually doing its job. Also, if you ran it
from the command line as root or the nagios user, the script worked
fine. Complicating things is the fact I am using the embedded perl
interpretter (p1.pl). Also interestingly enough, another event
handler script I wrote that is nearly identical to this one does not
suffer the same problem.
Well here is why my script wasn't working:
In check_commands.cfg, I had these lines for these two event handlers:
---------------
define command {
command_name fix_script_that_works
command_line
$USER1$/event/fix_script_that_works -S $SERVICESTATE$ -T
$SERVICESTATETYPE$ -A $SERVICEATTEMPT$ -H $HOSTADDRESS$
}
define command {
command_name fix_script_that_breaks
command_line
$USER1$/event/fix_script_that_breaks -S $SERVICESTATE$ -T
$SERVICESTATETYPE$ -A $SERVICEATTEMPT$ -H $HOSTADDRESS$ -a A
}
---------------
Well, there you go! Can you see the problem? As it ends up, I could
use the exact same script, but write the command definitions slightly
differently and one would break and the other would not!
The problem is that there were 2 spaces between
"$USER1$/event/fix_script_that_breaks" and "-S" while only 1 space
between "$USER1$/event/fix_script_that_works" and "-S". (I did this
to simply even up the columns in the config file to satisfy my O/C
urges).
Well, that extra space causes the embedded perl interpretter to make
$ARGV[0] be equal to '' (the empty string) and as a result, causes
getopts to fail silently in taking in options off of the command line.
(Note that when you run a script off of the command line (say in
bash), you can use any number of spaces between the program name and
the first argument). The script I was using defaulted to values that
would cause the event handling code to not run, so that explains why
the event handler never did anything.
Anyway, I hope this saves someone some frustration.
~trasko
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list