up one more time to try and get a feel for people's thoughts.
Personally, I would prefer not to skip empty lines of plugin output in
an effort to find the first line of text - that should be fixed in plugins.
However, grabbing output from stderr might be of interest to people for
debugging purposes as Bob mentioned. Is there sufficient interest to
justify a patch of some kind? If so, how would the output from stderr
be treated? Would it go into a macro other than $HOST/SERVICEOUTPUT$,
or would it be best to tag it onto the end?
[email protected] wrote:
> That's wonderful, but what about capturing stderr for diagnostics?
>
> This is where a good portion of the problems appear when something goes
> wrong and needs to be debugged?
>
> I think it would be a grand idea make the parent process prove stderr
> diagnostics if stdout has nothing to say.
>
> As an aside, is there a way I can get involved in the 3.x series
> discussions/development? If nothing else, I'd sure like to see what's
> coming around the corner and perhaps help out...
>
> Bob
>
>> Thomas Sluyter wrote:
>>> On 25 Oct, 2006, at 0:08, [email protected] wrote:
>>>
>>>> But being a lazy programmer, I am thinking, why not just have
>>>> Nagios be a
>>>> little more forgiving and inquisitive and keep searching stdout
>>>> until it
>>>> finds the first non-empty line? Is that so bad? Or is it a feature?
>>> You'll like Nagios 3 when it comes out. It'll allow you to read
>>> multiple lines of stdout. So be patient, little grasshopper.
>>>
>>> Cheers! o/
>>>
>>>
>>> Thomas
>>>
>> As Thomas mentioned, Nagios 3 will support multiple lines of output from
>> plugins, so this patch would break that future feature.
In Nagios 3>> any output after the first line will get thrown into either the
>> $LONGSERVICEOUTPUT$ or $LONGHOSTOUTPUT$ macros, depending on what type
>> of check was performed. There is also a 4K or 8K limit on the output
>> size to prevent runaway plugins from returning too much data.
>>
>>
>> Ethan Galstad,
>> Nagios Developer
Ethan Galstad,
Nagios Developer
---
Email: [email protected]
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]