NSClient++ Checkfile2 error


#1

Hi folks

I’ve got an issue with the NSCLient++ (0.3.7.494) Checkfile2 nrpe module and I was wondering if anyone experienced anything similar.
I’m trying to monitor a folder on a Windows 7 machine from a Centos 5.5 nagios server running nagios version 3.2.1. All I want to do is send an alert when the folder contains so many items. At the moment I’ve been testing remotely from the command line against a folder that contains 1 item using the following command:

running this command returns the following:

However, this code should return “Critical” as there is a file already in there…

When I’m running the nsclient using the test mode, I can see the connection on the target machine as follows:

d NSClient++.cpp(1073) Injecting: CheckFile2: MaxCrit=1, path=C:Test pattern=*.* d \CheckDisk.cpp(116) Input is: C:Test pattern=*.* / ffffffff d \CheckDisk.cpp(119) Found a file dont do recursive scan: C:Test pattern=*.* d \CheckDisk.cpp(334) Looking for: path: C:Test pattern=*.*, pattern: C:Test pattern=*.* d \CheckDisk.cpp(122) Path is: C:Test pattern=*.* d NSClient++.cpp(1109) Injected Result: OK 'CheckFile ok' d NSClient++.cpp(1110) Injected Performance Result: ''no files found'=0;0;1; '
I’ve spent quite a lot of time on this trying various configurations and have the feeling that I’m going round in circles. I’m wondering if I’ve got my syntax all wrong or something like that…

I would very much appreciate a fresh perspective on this - to be honest it’s driving me a little mad :).

Thanks in advance.

Kev


#2

First off the :es need to be escaped from the command line on *nix.

So try either c:\foo\bar or ‘c:\foo\bar’ or some such.

Secondly a lot of “error/debug information” was added in the 0.3.8 release (for checkfile2) so IO would recommend upgrading.

Also in 0.3.8 there is a new option called debug to enable some nifty debug information to be printed to help resolve such issues:

// Michael Medin


#3

Hi Michael, thanks for the reply, I’ve already tried escaping the special characters. I’ve tried the variants below:

./check_nrpe debug=1 -H xxx.xxx.xxx.xxx -p 5666 -c CheckFile2 -a MaxCrit=1 path=C:\\Test\\ pattern=\*.\* ./check_nrpe debug=1 -H xxx.xxx.xxx.xxx -p 5666 -c CheckFile2 -a MaxCrit=1 path="C:\Test\" pattern="*.*" ./check_nrpe debug=1 -H xxx.xxx.xxx.xxx -p 5666 -c CheckFile2 -a MaxCrit=1 path='C:\Test\' pattern='*.*'

In all cases I got the following errors on the target windows machine:

e \NRPEListener.cpp(403) Request arguments contained illegal metachars! e \NRPEListener.cpp(365) NRPEException: Request command contained illegal metachars!
However, where I’ve added single or double quotes, the bash interpreter seems to expect another quote. So after running the command, I am left with a “>” symbol and a blinking cursor.
I’ve also upgraded the NSClient (to 0.3.8.76) as you suggested and have re-run the original command.

which now gives me the error:

So I’ve added a filter argment (which I hope is correct) as follows:

which gave the following error on the target windows machine:

d NSClient++.cpp(1106) Injecting: CheckFile2: MaxCrit=1, path=C:Test pattern=*.* , filter=in, filter+size= d NSClient++.cpp(1142) Injected Result: WARNING 'Unknown filter key: (numeric f ilters have to have an operator as well ie. foo=>5 or bar==5)' d NSClient++.cpp(1143) Injected Performance Result: ''
as you can see the filter+size operator is blank, but escaping the special character in this section (so it reads filter+size=>0) returns the following errors:

e \NRPEListener.cpp(403) Request arguments contained illegal metachars! e \NRPEListener.cpp(365) NRPEException: Request command contained illegal metachars!
as an aside… On some of my testing I encountered the following error:

However, I’ve not seen any such directive in the nsc.ini file and adding show_errors=1 in the file seems to do nothing. I would like to enable this if possible and also would appreciate it if you could explain to me how to enable this “debug” feature that you spoke of earlier.

Thanks a lot for your help on this! I feel like it’s just a small syntax error I’m making somewhere but my brain is so frazzled now I don’t think it’s capable of finding it without help!

Cheers

Kev


#4

This all went a bit quiet but I managed to resolve the issue myself…

I modified the NSC.ini on the client machine to include the following:

Then by using the following command:

I got the following output.

Hooray!

Maybe this might help someone who was making the same silly mistake as I was :slight_smile:

Thanks Mickem for your initial help :slight_smile: