[Nagiosplug-devel] check_load arg parsing bugfix and cleanup

[Andreas Ericsson]

sean finney wrote:
> hi andreas,
> 
> On Sat, May 28, 2005 at 03:52:22AM +0200, Andreas Ericsson wrote:
> 
>>It's at http://oss.op5.se/nagios/runcmd.tar.gz. It's basically a 
>>revamped spopen() with an output-buf-to-stringarray parsing-routine 
>>attached. I've made sure that used values aren't wasted so the 
>>complexity of parsing multi-line output is no O(n) instead of O(n+m) 
>>like it was before. It makes for quite a save on multiple serial executions.
> 
> 
> i've taken a look over this, and have a couple questions/comments, which
> i'll share for the benefit of those who probably aren't going to read
> through it otherwise:
> 
> first off, i notice some pretty major interface changes to spopen.

Yes. This was necessary to make it async safe while maintaining 
simplicity. The function must be renamed however, since its interface 
doesn't match that of popen any more.

> instead of dealing with FILE pointers we're now dealing with int fd's
> (or piped pairs, actually).  secondly, these are now passed as additional
> params to the function, instead of existing as global variables.
> 

Also for async safety reasons, but the plugins should only call
exit_code = np_runcmd(command, &chld_out, &chld_err, flags);
and never worry about anything else (the flags parameter is a new 
addition which makes it possible for plugins decide if they want the 
output->line array populated or not).

> this would mean going through all the nagios plugins code and making
> some fairly heavy modifications.

Not all that heavy actually since it will mostly involve removing a lot 
of redundant code. I'll take care of that, so there'll be no need to 
worry about it.

>  however, i see this being a generally
> beneficial thing in the long run--mainly because of code reduction
> but also because it's generally more friendly towards multithreaded
> environments (not that i think any plugins will be multithreaded, but
> certainly a good thing if this were eventually headed for nagios core).
> 
> about the runcmd functions:  any reason not to have "output" be a struct
> that contains datastructures for both stdout and stderr, and only pass
> one argument to the functions?
> 

The output structure is fairly general and can be used for other things 
as well (getting data from a network socket, reading files, etc. etc.)

If all of it is in the same struct that would mean symbol names will 
differ further from the start so the linker takes longer to resolve the 
symbols.

It should be possible to choose what output one is interested in so the 
caller should be able to send NULL instead of a struct.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer