check_proc -a works directly but fails through nrpe

[R. David Murray]

This is weird.  If I do this:

    >sudo -u nagios /usr/local/libexec/nagios/check_procs -a "-L /var/sipenv-10.1.2.1/log/b2bua.log" -C python -c 1:1
    PROCS OK: 1 process with args '-L /var/sipenv-10.1.2.1/log/b2bua.log', command name 'python'

everything is fine, but if I do it remotely:

    >./check_nrpe -H 65.175.131.174 -c check_foo
    PROCS CRITICAL: 0 processes with args '-L /var/sipenv-10.1.2.1/log/b2bua.log', command name 'python'

it can't find the process.  It looks as though the string that check_cpu
is looking at is truncated when and only when it is run under nrpe.

Anyone have any clues, especially thoughts on a workaround?

Here is various version info:

    >uname -a
    FreeBSD xxxxx 6.3-RELEASE-p1 FreeBSD 6.3-RELEASE-p1 #4: Thu Nov 20 15:52:07 EST 2008
    >./check_procs --version
    check_procs v1991 (nagios-plugins 1.4.12)

    >/usr/local/sbin/nrpe2 --version
    nrpe2: unrecognized option `--version'

    NRPE - Nagios Remote Plugin Executor
    Copyright (c) 1999-2007 Ethan Galstad (nagios at nagios.org)
    Version: 2.7
    Last Modified: 02-19-2007

The remote host is Red Hat EL4, but I doubt that makes a difference, especially
since the same thing happens if I run check_nrpe2 on the FreeBSD machine
to 127.0.0.1.


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
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