oscp_command never runs

[Marc Powell]

> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
> admin at lists.sourceforge.net] On Behalf Of Ludwig Pummer
> Sent: Tuesday, September 06, 2005 5:30 PM
> To: nagios-users at lists.sourceforge.net
> Subject: [Nagios-users] oscp_command never runs
> 
> Let me start off by saying I've already searched the mailing list for
this
> issue and checked for issues mentioned in those messages. Of course,
it's
> possible that I didn't find (and therefore didn't check for) the issue
> which is causing my problem...
> 
> I'm running Nagios 1.2 compiled from source package on FreeBSD. I'm
> experimenting with setting up distributed + failover monitoring, so my
> configuration is fairly small and clean. Right now, I'm trying to make
> 'boba' send its service check results to 'jango' using the
ocsp_command.
> 
> My nagios.cfg has:
> ocsp_command=submit_check_result_smart
> ocsp_timeout=5
> obsess_over_services=1
> use_retained_program_state=0
> I've also turned on all logging options except the initial state
option.
> 
> My services.cfg template for all of the services has:
> obsess_over_service             1
> 
> my misccommands.cfg has:
> define command{
>         command_name    submit_check_result_smart
>         command_line
> /usr/local/nagios/libexec/eventhandlers/submit_check_result_smart
> $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$OUTPUT$'`
> }
> 
> I have 4 hosts and 6 services configured (1 PING on each host, and
NRPE
> check_nagios on 2 of the 4 hosts) and they've been running fine.
> 
> My event handler does a lookup on the hostname passed to it and then
calls
> send_nsca. It also writes a line to its own log file with the
arguments
> passed to it.
> 
> If I manually run this event handler as the nagios user:
> root at boba# su -l nagios
> /usr/local/nagios/libexec/eventhandlers/submit_check_result_smart
jango
> 'PING' OK 'test ping time 0.4ms'
> 1 data packet(s) sent to host successfully.
> root at boba#
> 
> My event handler's log after the above manual run:
> submit_check_result_smart called with 1:jango 2:PING 3:OK 4:test ping
time
> 0.4ms, found;1, return_code:0
> 
> On host jango, in nagios.log, I see:
> EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;jango;PING;0;test ping
time
> 0.4ms
> 
> Nagios doesn't find any errors in my config (just 1 warning about a
> contact not belonging to a contact group), and I've stopped it,
removed
> the status.sav file, and restarted it. The CGI interface's Process
Info
> page on boba says that Obessing is enabled. I see nothing in my
nagios.log
> about the ocsp_command being run, and my submit_check_result_smart
> script's log file never shows that the command was run.
> 
> Anyone have any ideas why the ocsp_command is not being executed?

Not really. Everything looks correct as detailed above. My next step
would be to simplify the submit_check_result_smart command to at least
give a direction to look --

define command{
        command_name    submit_check_result_smart
        command_line    /bin/echo "I ran for '$SERVICEDESC$' on
$HOSTNAME$"  > /tmp/ocsp
}

Make sure that nagios really is restarting as well. Nagios doesn't
normally log OSCP execution but you may be able to see those by
recompiling with a higher debug level. There haven't been any problems
with the OCSP code for as long as I can remember so you probably don't
need to do that.

--
Marc


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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