Nagios Support Forum

So I looked around in core source but couldn't figure
it out. I've tried to increase MAX_INPUT_BUFFER in
common/common.h from 1024 to 2048 bytes, but still my
passive check results are getting chopped off.
Surprisingly, after this change PLUGIN_OUTPUT is
getting truncated to 942 bytes while before above
change it was 937 bytes.

Is there some other buffer limit hardcoded somewhere
pertaining to size of check results that are being
written to command file (besides
MAX_PLUGINOUTPUT_LENGTH and MAX_INPUT_BUFFER)?

Thanks,
Pete

--- Peter Kostik wrote:

> Thanks for a tip. You're right. I tested it with
> nonexistent cmd file and was able to receive full 2k
> plugin output on Nagios box (in the alternate
> nsca.dump file). So now I know that problem is with
> Nagios. I'll try to poke around the code to see if I
> can figure it out.
>
> Thanks again.
>
> --- Subhendu Ghosh wrote:
>
> > Sorry - missed the nagios mod.
> >
> > Have you tried pointing nsca.cfg to a
> non-exisitent
> > cmd file and specified
> > an alternate dump file and checked the results?
> >
> > -sg
> >
> > On Thu, 21 Jul 2005, Peter Kostik wrote:
> >
> > > Thanks for a quick reply. However, as I stated
> in
> > my
> > > original post, I did change
> > MAX_PLUGINOUTPUT_LENGTH in
> > > both nsca and nagios to 2k. I also changed
> > > MAX_INPUT_BUFFER from 2k to 8k in nsca.
> > >
> > > Pete
> > >
> > > --- Subhendu Ghosh wrote:
> > >
> > >> nagios/include/objects.h
> > >> objects.h:#define MAX_PLUGINOUTPUT_LENGTH
> > >> 348
> > >>
> > >> Nagios itself has a limit - that can be changed
> > as
> > >> you are doing for NSCA
> > >> - provided all your platforms support the size
> as
> > >> less than PIPE_BUF
> > >>
> > >> -sg
> > >>
> > >> On Thu, 21 Jul 2005, Peter Kostik wrote:
> > >>
> > >>> My monitored system is Solaris 8. From
> limits.h:
> > >>>
> > >>> PIPE_BUF 5120 /*
> > max
> > >> #
> > >>> bytes atomic in write to a pipe*/
> > >>>
> > >>> As you can see ~5k is more than enough for my
> > 1.8k
> > >>> plugin outputs. Nagios host is RHEL4 and as
> you
> > >>> pointed out correctly PIPE_BUF is 4k, but I
> > don't
> > >>> think it matters b/c message comes to Nagios
> > >> truncated
> > >>> to 937 bytes. This is how I send alarms in my
> > >> plugin
> > >>> via send_nsca (perl):
> > >>>
> > >>> open(NSCA,"|$notifyCmd") or die ("ERROR:
> Cannot
> > >> pipe
> > >>> to $notifyCmd: $!");
> > >>> print NSCA $notifyMsg;
> > >>> close(NSCA);
> > >>>
> > >>> Anyone has similar problem or can think of a
> > >>> workaround?
> > >>>
> > >>> Thanks,
> > >>> Peter
> > >>> --- Subhendu Ghosh wrote:
> > >>>
> > >>>> On Mon, 18 Jul 2005, Peter Kostik wrote:
> > >>>>
> > >>>>> Hello all,
> > >>>>>
> > >>>>> by saying what an incredibly superior
> product
> > >>>> Nagios
> > >>>>> is, I will be probably repeating hundreds of
> > >>>> others
> > >>>>> that use it and love it, so let me get to
> the
> > >>>> point.
> > >>>>>
> > >>>>> I am running 2.0b3 to monitor thousands of
> > >>>> services on
> > >>>>> hundreds of servers, using mainly passive
> > checks
> > >>>>> (nsca/send_nsca) and of course
> nrpe/check_nrpe
> > >> to
> > >>>> make
> > >>>>> sure things are running as they should.
> > >>>>>
> > >>>>> Some of my plugins return long outputs (2k)
> > via
> > >>>>> send_nsca. So what I did is increase
> > >>>>> MAX_PLUGINOUTPUT_LENGTH in common/common.h
> in
> > >> nsca
> > >>>>> addon and also in core nagios in
> > >>>> include/objects.h. I
> > >>>>> believe original value was something around
> > 300
> > >>>> bytes
> > >>>>> so I bumped it up to 2k. However, my plugin
> > >>>> outputs
> > >>>>> still get truncated at around 800 bytes
> (don't
> > >>>> know
> > >>>>> exact value of top of my head). Had anyone
> > >> played
> > >>>>> around with changing these values and got it
> > >>>> working
> > >>>>> right? I am wondering if there is another
> > limit
> > >>>> set
> > >>>>> somewhere else that overrides this.
> > >>>>>
> > >>>>> Thanks for the g

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]