Page 2 of 3

Re: NRPE: Command not defined

Posted: Mon Nov 15, 2021 5:23 pm
by gsmith
HI,

Please go to Configure, CCM and click on the Hosts box.
If both localhost and NagiosXI_Local_Server are there please
delete one of those hosts. I am thinking your phantom Unknown Disk Usage
is associated to localhost so it would make sense to delete NagiosXI_Local_Server
and then tweak the values of the localhost if you want it to be known as
NagiosXI_Local_Server.

Thanks

Re: NRPE: Command not defined

Posted: Tue Nov 16, 2021 7:33 pm
by matson-itops
I think we're confusing tickets here.

lets focus on the command not defined issue here.

Re: NRPE: Command not defined

Posted: Tue Nov 16, 2021 7:35 pm
by matson-itops
any update on the nrpe command not defined issue?

Re: NRPE: Command not defined

Posted: Wed Nov 17, 2021 10:27 am
by gsmith
Hi

Let's look at the command definitions.

On your mail server go to /usr/local/nagios/etc
and edit nrpe.cfg. Is the check_mailq command defined there?

If so, is the plugin installed where the [command]check_mailq is pointing to?

Thanks

Re: NRPE: Command not defined

Posted: Mon Nov 29, 2021 11:24 am
by matson-itops
hope you had a good holiday break
here is my response

on mail server

[jlin]$ pwd
/usr/local/nagios/etc

[jlin]$ more nrpe.cfg | grep mailq
command [check_mailq]=/usr/local/nagios/libexec/check_mailq -w $ARG1$ -c $ARG2$

[jlinc]$ ls -al /usr/local/nagios/libexec/check_mailq
-rwxr-xr-x 1 root nagios 25589 Nov 5 11:03 /usr/local/nagios/libexec/check_mailq

Re: NRPE: Command not defined

Posted: Mon Nov 29, 2021 5:16 pm
by ssax
Is there a space between command and[check_mailq] in your nrpe.cfg (there is in what you posted but that could be a copy/paste anomaly)? If so, please try removing the space and then restart xinetd or the nrpe service (however you're running it), and then run the check again.

If that doesn't resolve it, please attach your nrpe.cfg from the remote system.

What is the output of these commands on the remote system?

Code: Select all

find / -name nrpe.cfg
ps aux | grep nrpe
cat /etc/xinetd.d/nrpe

Re: NRPE: Command not defined

Posted: Wed Dec 01, 2021 6:23 pm
by matson-itops
OMG I think that was it. got back command not defined.

now i'm getting on the nagios server

[nagios ~]$ /usr/local/nagios/libexec/check_nrpe -H x.x.x.x -t 30 -c check_mailq -a '-w 100 -c 200 -M sendmail'
Usage: check_mailq -w <warn> -c <crit> [-W <warn>] [-C <crit>] [-M <MTA>] [-t <timeout>] [-s] [-d <CONFIGDIR>] [-v]

but its working on the server
root@]# ./check_mailq -w 100 -c 200
OK: sendmail mailq (4) is below threshold (100/200)|unsent=4;100;200;0

has anyone seen this before?

Re: NRPE: Command not defined

Posted: Thu Dec 02, 2021 12:29 pm
by ssax
Does this work?

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H x.x.x.x -t 30 -c check_mailq -a 100 200
I think for this:

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H x.x.x.x -t 30 -c check_mailq -a '-w 100 -c 200 -M sendmail'
You would need this nrpe.cfg command defined:

Code: Select all

command [check_mailq]=/usr/local/nagios/libexec/check_mailq $ARG1$

Re: NRPE: Command not defined

Posted: Thu Dec 02, 2021 12:46 pm
by matson-itops
thank you SSAX its working now

after fixing the space I had to do a small tweak , below is the working config

On nagios server
[nagios ~]$ /usr/local/nagios/libexec/check_nrpe -H x.x.x.x -t 30 -c check_mailq -a 100 200
OK: sendmail mailq (3) is below threshold (100/200)|unsent=3;100;200;0

On server
[x.x.x.x]# more nrpe.cfg | grep mailq
command[check_mailq]=sudo /usr/local/nagios/libexec/check_mailq -w $ARG1$ -c $ARG2$

I also had to tweak the mailq script for sudo on the mail server
[x.x.x.x]# diff check_mailq check_mailq_orig
322c322
< if (! open (MAILQ, "/usr/bin/sudo $utils::PATH_TO_MAILQ$mailq_args | ")) {
---
> if (! open (MAILQ, "$utils::PATH_TO_MAILQ$mailq_args | ")) {

Re: NRPE: Command not defined

Posted: Fri Dec 03, 2021 10:59 am
by ssax
That's great to hear! Since you have sudo on the nrpe command you likely don't need to change check_mailq to add sudo to it as it would already be running in the sudo context.

Let us know when we're okay to lock this up and mark it as resolved.