check_proc -a works directly but fails through nrpe

[R. David Murray]

Jon Angliss <jon at netdork.net> wrote:
> On Wed, 29 Apr 2009 22:03:46 +0000 (UTC), "R. David Murray"
> <rdmurray at bitdance.com> wrote:
> 
> >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?
> 
> What's your definition for check_foo from the nrpe?  You mentioned
> check_procs in the first statement, check_foo in the command call, and
> check_cpu in the explanation of truncation... which is right? ;)

The nrpe.cfg definition of check_foo is:

command[check_foo]=/usr/local/libexec/nagios/check_procs -a "-L /var/sipenv-10.1.2.1/log/b2bua.log" -C python -c 1:1

The mention of check_cpu should be replaced with check_procs, sorry for the typo.

--
R. David Murray                 http://www.bitdance.com


------------------------------------------------------------------------------
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