[Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins

[sean finney]

hey guys,

On Thu, Jan 04, 2007 at 05:08:53PM +0100, Andreas Ericsson wrote:
> > 1.4.5 has some spopen calls in check_fping.c check_hpjd.c check_load.c
> > check_ping.c check_procs.c check_snmp.c check_swap.c and check_users.c.
> > 
> 
> Ah, righto. I don't use the official version myself and I've hacked 
> those instances away in our version.

for the record, way back when i merged in the runcmd stuff (2004 or
so?), a good number of the plugins either had trouble compiling or
would segfault.  iirc, the ones which had trouble i left with the
spopen calls to have a later look, since at the time we were getting
close to making a release.

> > But true: it would cost very much initially to rewrite that all. I think
> > nobody wants to do that without a need.
> > 
> 
> Yes. It all piles up rather quickly. To be honest, I like the fact that 
> plugins are external programs. Mainly because it allows fast and 
> free-style development in any language the system you're on can run, but 
> also because it allows drop-in replacement of plugins without having to 
> restart Nagios.

and also for posterity... around the time i mentioned above, andreas and
i had a long and drawn out conversation about possibly "embedding"
plugins by compiling them as .so libraries and use of dlopen().  this
would allow for removing 2 of the 3 fork calls involved in each popen()
type call (iirc), and would remove the need to exec() anything.

unfortunately, this comes at the cost of many memory leaks (not many
plugins bother to even call free()), possible crashing of the nagios daemon,
and lots of code-rewriting... and the performance increase is only
marginal since in most cases the real bottleneck is the first fork/exec
call being done serially from the nagios daemon.  better would be to
remove/rewrite the fork/exec bottleneck by having a pool of worker
threads that could do it in a more parallel fashion--this was also a
result of the old discussion iirc.


	sean