Custom Plugin

EXT-Fuentes, James P James.P.Fuentes at boeing.com
Thu Jul 21 00:50:59 CEST 2005


That sounds very much like a problem I ran into with rsh.
 
I wrote a script which collects data from a host via rsh commands and depending on the contents of that data I'd send the appropriate exit status to Nagios as outlined in the plugin development doc.
 
I'd run the script from the command line and it would behave exactly as I expected it to. However, when I defined a checkcommand and a service in Nagios I would always get an "OK" status and "No output" in the comment field in Nagios no matter what I set my thresholds to (Drove me nuts).
 
It turns out, because my checkcommand simply ran and completed, it always returned an exit status of 0 and the results of my rsh command, by default, would go to /dev/null when spawned from my checkcommand.
 
There is a "-n" option for rsh which redirects input from device /dev/null, thus getting it to Nagios reflecting the actual status of the remote host. Once I implemented this, things work perfectly.
 
I realize your method differs from mine but it seems you're doing something functionally similar and your results sound identical to my initial results. I would check man pages to see if there is an equivalent option for you.
 
-Jim

________________________________

From: Danny Russell [mailto:drussell at mpifix.com]
Sent: Wed 7/20/2005 10:44 AM
To: nagios-users at lists.sourceforge.net
Subject: [Nagios-users] Custom Plugin



I am trying to monitor a host that is behind a Cisco VPN Concentrator. For simplicity right now I am just trying to use check_ping.

 

I have written an expect script (lhm.sh) that logs into the VPN and then runs a check_ping command. Here is the code for lhm.sh:

     1    #!/usr/bin/expect -f

     2    set cmd_one [lindex $argv 0];

     3    log_user 0

     4    spawn vpnclient connect lhm pwd password

     5    expect "(y/n): " {send "y\r"}

     6    spawn ./check_ping -H $cmd_one -w 3000.0,80% -c 5000.0,100% -p 3

     7    interact

     8    set status [wait]

     9    #puts [lindex $status 3]

    10   exit [lindex $status 3]

 

Line #3 - disables the output to go to stdout. This hides all of the nasty long VPN connection information.

Line #4 - connects to the VPN

Line #5 - sends a 'y' so the VPN is connected

Line #8 - gets the exit return code

Line #10 - exits with the exit return code from $status.

 

When I call './lhm.sh 10.30.31.51' this is the output:

[root at monitor plugins]# ./lhm.sh 10.30.31.51

PING OK - Packet loss = 0%, RTA = 60.68 ms

[root at monitor plugins]#

 

When I call './lhm.sh 10.30.31.51' with the puts un-commented this is the output:

[root at monitor plugins]# ./lhm.sh 10.30.31.51

PING OK - Packet loss = 0%, RTA = 71.03 ms

0

[root at monitor plugins]#

 

When I call './lhm.sh 10.30.31.61' (A WRONG IP) with the puts un-commented this is the output:

[root at monitor plugins]# ./lhm.sh 10.30.31.61

CRITICAL - Plugin timed out after 18 seconds

2

[root at monitor plugins]#

 

The problem is, when I create a custom check command in /etc/Nagios/checkcommands.cfg to call /usr/lib/Nagios/plugins/lhm.sh Nagios always reports it as up and (No output!). It even reports at UP if I give it a wrong IP (10.30.31.61).

Host Status:  UP    

Status Information:(No output!)

 

Any ideas?

 

 

Thanks!

Danny Russell

Mobile Productivity, Inc.

drussell at mpifix.com

work-801.437.5885 mbl-801.722.5837

Enabling the World To Work

 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
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