I have had NSclient++ working with Nagios for a while now. Recently I started testing Nagwin just to see how it would work, out of pure curiosity. I stopped checking a test server with my main Nagios config, set NSclient++ to NRPE mode, and pointed Nagwin at it. It worked great for a few hours then suddenly I started seeing "UNKNOWN: No Handler for that command." I figured it has to be Nagwin's fault since it's so new, I'll just unload NRPElistner.dll and return my server to being monitored by check_NT. However now check_NT doesn't work my main Nagios server returns timeout errors and is unable to connect at all. My Nagwin server can connect to it, the server just doesn't know how to handle the check_NRPE commands even though it did with no changes a few hours earlier.

I have been working on this for a day now and am fairly certain it is NSclient++ who is to blame here. My nagwin box has successfully stayed connected to a similar server throughout the night, without any issues. And my main Nagios config is not having any problems at all. I have been able to successfully switch another server between being monitored by nagios and nagwin without any problems by simply loading and unloading the NRPE.dll. I have tried uninstalling NSclient++ and reinstalling with fresh configuration but still receive the errors. As of now the firewall is off on the server, NSclient++ is setup to accept connection from any server, there is no password, I have also turned ssl off, and the NRPE module is loaded. Any Ideas would be appreciated, I am not an advanced Nagios user but I do know my way around it and can easily break it down and set it up again.

I also want to add that while in test mode NSclient++ is unable to handle check_NRPE commands there either.

  • Have you tried testing by telneting to the NRPE port & running the checks manually with check_nrpe ? – jamespo Feb 16 '11 at 14:43
  • @jamespo thats what the test mode does in NSclient++, it allows you to test running remote commands locally. – Not Kyle stop stalking me Feb 16 '11 at 14:44

This might seem like a silly answer but I had a similar issue and it turned out to be a bug in the version of nsclient++. I would recommend upgrading to the latest stable version and see if the issue still occurs.

If a fresh configuration file isn't working it does sound like an issue with nsclient++. In this case it might be worth posting a bug for them to take a closer look: http://www.nsclient.org/nscp/newticket or there may already be a bug similar to this in their database.

Also it may be a .dll issue, worth checking event viewer on the machine for additional errors.

Hope this helps you.

  • I ended up changing my client to winNRPE no problems with NRPE since. It connected fine on the same box and I just copy and pasted my NRPE handlers into winNRPE. So I suppose you were right about a possible bug in NSclient++ so I'll accept this answer since there is no definitive cause of this issue. – Not Kyle stop stalking me Mar 7 '11 at 13:38

First off there is no "check_nrpe" command in test mode. NSClient++ is (amongst others) a NRPE broker with a lot of built-in internal commands.

The normal way to diagnose this would be to:

  1. stop the service.
  2. start nsclient++ in "test" mode. (ie. nsclient++ /test)
  3. wait...
  4. check what the log says when the call comes from Nagios (or what you prefer).
  5. Fix whatever the problem is (normally things like this is related to, SSL configration issues, allowed host configuration issues, and what not).
  6. (re)start the nsclient++ service

Another option would be to check the log file and/or enable debug logging. Without "this information" it is very difficult to diagnose.

// Michael Medin

  • It was a bug in the NSclient++ it didn't have any NRPE handlers the section <NRPE Handlers> was missing in the config file... logs showed exactly that "no handlers for that command" Pablo was 100% right and either way I started using the ops view nsclient after putting their front end on nagios... problems solved. – Not Kyle stop stalking me Mar 31 '11 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.