Processes hanging - Nagios 3rc1 on FreeBSD

[Alex French]

On 28/12/2007, ad at heapoverflow.com <ad at heapoverflow.com> wrote:
> Hmmm I would try running the command from the SSH shell directly first
> to check if it runs fine, or you can try out with strace to have a
> debug output like:
>
> strace check_...... 2>&1 | egrep '()' > /tmp/strace.log
> strace perl -W check_...... 2>&1 | egrep '(access|open)' > /tmp/strace.log
>
> it sounds like a file permission problem you may solve quickly with
> strace

That's what I was thinking too, but the commands do run fine, and
their output gets saved to the checkresults temporary file. For
example, running check_ping gives this on the cmd line:

> ./check_ping -H localhost -w 3000.0,80% -c 5000.0,100% -p 5
PING OK - Packet loss = 0%, RTA = 1.26 ms


and I can see files like this in the checkresults dir:

> cat /var/spool/nagios3/checkresults/checkLSzkYX
### Active Check Result File ###
file_time=1198838164

### Nagios Host Check Result ###
# Time: Fri Dec 28 10:36:04 2007
host_name=localhost
check_type=0
check_options=0
scheduled_check=1
reschedule_check=1
latency=0.733000
start_time=1198838164.733798


I'm wondering if it's a problem with the child process reporting these
back to the parent nagios process, but I don't know how I can debug
that as the child process does not seem to log anywhere or provide
debug... for example, where do the pipes actually live?

I've also read some threads about pipe sizes causing similar problems,
but that would seem only to apply in the case of lots of services.

Any advice appreciated.

Alex

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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