NSClient++ Help (#1) - \execute_process.hpp:114: Failed to peek buffer: 109: The pipe has been ended. [SOLVED] (#280) - Message List

\execute_process.hpp:114: Failed to peek buffer: 109: The pipe has been ended. [SOLVED]

NSClient++ - 0.3.5.2 2008-09-24 Nagios Version 3.0.1 NRPE checks.

I've tried to customize the NSClient++ MSI to install only the bare essential DLL required for just check_nrpe commands to run .wsf scripts. This allowed me to run one setup with cutom NSC.ini files already pre-configured. These are some of the checks I have:

Example: check_nrpe - Dell OMReport check_nrpe Available RAM check_cputime check_disk_c check_nrpe - process.exe

I've removed some unneeded modules from the The only Modules from the
NSClient++\modules folder, and only have the following: FileLogger.dll NRPEClient.dll NRPEListener.dll SysTray.dll

Everything seems to work fine as far as the checks go. However, when I view my NSC.log, I see the following line that correspond to the time Nagios initiates the checks (every 3 minutes):

2008-11-05 18:41:18: error:d:\documents\Visual Studio 2005\Projects\NSCP\branches\stable\include\execute_process.hpp:114: Failed to peek buffer: 109: The pipe has been ended.

Can you help me to find out what this means please. Did I remove something that I shouldn't have from the Modules folder?

Thanks

  • Message #863

    No cant see anything thats removed. My guess would be there is a problem with the executable you are trying to run.

    Which check and what kind of "command" is it you are trying to run? If you run in /test mode you can probably figure out which command is causing the error.

    MickeM

    • Message #864

      Thanks for the quick reply MickeM

      The main command I'm running is configured in Nagios as:

      define command {

      command_name check_nrpe command_line /usr/local/nagios/libexec/check_nrpe -H $HOSTADDRESS$ -c $ARG1$

      }

      # service_id_5_100 define service {

      use generic-service host_name host.local service_description Available RAM display_name check_nrpe Available RAM check_command check_nrpe!check_ram contact_groups Myself

      }

      And on the NSC.ini, under NRPE Handlers, it's referenced as: check_ram=cscript.exe NoLogo T:10 c:\NSClient++\scripts\check_ram.wsf /w:20 /c:10

      and in \NSClient++\scripts, the file is: check_ram.wsf

      and I have similar checks for check_dell_omreport.wsf check_dell_sensors.wsf check_disk.wsf check_process.wsf chkwin_cputime.wsf

      So far, running NSClient++ /test does not produce any errors. Do you think this has anything to do with TLS/SSL socket connections? I really don't know what to make of the error: Failed to peek buffer: 109: The pipe has been ended.

      Thanks again for your response, and any light you can shed on this.

      • Message #865

        The error is very clear (to me) and noop nothing to do with SSL.

        When the NRPE "executor" (ExternalScripts/NRPEListsner) executes a "program" it creates a pipe to read the stderr (error messages) and stdout (messages) during the execution the pipes are polled for data and continuously read (so they wont fill up and lock down the process). The processes of "polling for new data" is (what I call?) called peeking and when it tries to do that the pipe has been closed which means "no more data is forth coming". This "should"(TM) (unless I have made a mistake) really not happen as stdout/stderr are closed by "me" when AFTER process has terminated. At which point I no longer "peek" inside them.

        Now this is not a "critical" error since all I do (when it happens) is to stop reading from the pipe. But still it is "strange" and it would be nice to know which command causes the problem (and hopefully why).

        Michael Medin

        • Message #872

          Michael,

          I'm getting exactly the same error while executing check_ad. The error does NOT appear in test mode. I've updated the NSClient from 0.2.7 to 0.3.5 recently. Here's the debug log section:

          2008-11-11 12:00:32: error:d:\documents\Visual Studio 2005\Projects\NSCP\branches\stable\include\execute_process.hpp:114: Failed to peek buffer: 109: Die Pipe wurde beendet.

          2008-11-11 12:00:32: error:.\NRPEListener.cpp:240: The command (check_ad) returned an invalid return code: 128

          2008-11-11 12:00:32: debug:.\NSClient++.cpp:946: Injected Result: WARNING 'No output available from command ("C:\Programme\Check_ad\check_ad.exe" -dc -noeventlog).'

          2008-11-11 12:00:32: debug:.\NSClient++.cpp:947: Injected Performance Result:

          I'm getting this error only on one of our DCs - strange. Could you please assist me on this? Thanks

          Martin

          • Message #873

            Then I would say it is a privilege issue. "ad" usualy requires you to have "administrator rights" which NSClient++ (local system IIRC) does not have, so you can either re-tool your AD or run the service (nsclient++) as another user.

            I would setup a local user with access to "just what is required" and use that user. Beware''' It it might be possible (depending on your setup) for a remote user to execute scripts as that user... just so you know... :)

            MickeM

            • Message #874

              Michael,

              thx for pointing me in the right direction. Here's how to solve it:

              1. open up properties of the NSClientpp-service
              1. in the "Log on" tab mark "Allow service to interact with desktop" checkbox
              1. restart the NSClientpp-service
              1. be happy

              hope it helps some other folks suffering the same problem ;-)

              Martin

      • Message #866

        it would (BTW) be interesting to know why you use an external script for checking RAM usage?

        Michael Medin

        • Message #867

          Thanks for the explanations Michael. It hasn't produced the error since running it in /test mode.

          I use the external script to check the RAM only because I wanted to limit the number of firewall port configurations to just one, TCP 5666. Plus I like the SSL/TLS option of NRPE for security.

          I'm going to run this overnight. I'll update this post on the rusults.

          • Message #868

            you can use the CheckMem (and many more) from NRPE as well if you include [CheckSystem]. Personally I always advocate NRPE over SSL over the pretty bad "NSClient protocol" (check_nt).

            And if you only get the error when you use it as a service you might wanna check the privileges required to run the script (since I am guessing you run it as administrator when you run it with /test.

            Michael Medin

            • Message #1698

              Hi,

              We are getting this same error.

              It is intermittent - on average 2-3 of times a week. We use NSClient++ on 20 machines. They range from XP, 2003, 2008 and 2008 R2. All receive this error with the same random intermittency. We've been running NSClient++ for at least 6 months with this issue from the beginning.

              We have a mix of 0.3.6.818 and 0.3.7.493 NSCLient++ client versions. It occurs on both.

              We use your standard [NSCA Commands] for purely passive checking with all data going one-way back to the Nagios server.

              Any ideas?

              mark

              • Message #1699

                Which command does it occur for?

                Presumable an external script and/or exe file?

                Michael Medin

              • Message #1700

                I am starting to think this is an erroneous error message. Is everything else working as it should?

                Michael Medin

                • Message #1708

                  We are only running your delivered scripts:

                  [External Scripts] check_ok=scripts\ok.bat

                  [NSCA Commands] host_check=check_ok Monitor: Client Ver=CheckVersion OS: Uptime=checkUpTime MinWarn=19h MinCrit=1h ShowAll OS: CPU Load=checkCPU warn=95% crit=98% time=10s ShowAll=long OS: Memory=checkMem MaxWarn=95% MaxCrit=98% type=physical ShowAll=long OS: Disk=CheckDriveSize MinWarnFree?=700M MinCritFree?=500M CheckAll? ShowAll=long

                  When the error occurs, the packet doesn't get sent to the nagios server and the nagios server thinks the host is down.

                  I'd have to turn on debug to see which command is in error. Will the following be sufficient?

                  [log] debug=0

                  • Message #1709

                    There is a built-in check_ok (CheckHelpers) which you can use presumably a lot faster if you care about that.

                    Michael Medin

                    • Message #1710

                      Will keep that in mid. At the moment speed is not the issue - reliability is. Any ideas what might be the cause of this error or how to diagnose where the problem is?

                      thanks

                      • Message #1721

                        I have removed the error message in the next nightly build.

                        (ie. check back in a day or so)

                        Michael Medin

Subscriptions