sean finney wrote:
> hey,
>
> On Mon, May 09, 2005 at 08:47:42AM -0700, [email protected] wrote:
>
>>From: Andreas Ericsson
>
>
>>Zero overhead is just not going to happen. Nagios MUST be able to
>>execute checks in parallell. It can't do that if it just enters a
>>function instead without forking, threading or multiplexing (actually it
>>can't do that without forking or threading, but popen() forks, so to
>>multiplex the results from it would be a sort of mix of both worlds), as
>>that would imply a serialized execution.
>
>
> you have a point that there's going to need to be some kind of fork
> or multi-threading capabilities. but calling a function in a forked
> process or thread would still be much better performance-wise than the
> multiple fork and exec calls in the current implementation.
>
Yes, but not by the ridiculous amounts your testcase showed, which is
why this is a questionable approach wrt the amount of work required to
make it work (two ends, plugins and core must be fixed).
>
>
>>It would require a huge re-design of current arch. It would also require
>>a huge re-design of most plugins, since they don't clean up after
>>themselves as it is today. They also use very shoddy function-calls. Not
>
>
> that wouldn't be as much of a "redesign" as it would be a code-cleanup,
> which is never a bad thing to do anyway. plus, what i'm suggesting
> isn't an all-or-nothing switchover, but a conditional switch. plugins
> could be audited for poor memory management etc and as they are approved
> added to a list of plugins to be added to the shared object target list.
>
I still don't buy it.
>
>>to mention; plugins that crash would cause nagios to crash. This just
>>isn't good enough.
>
>
> even forked children?
>
No, but threads in a worker list that picks up checks as they're ready
to run. This approach effectively puts a stop to all such approaches.
>
>>Three fork()'s and two execve()'s, as nagios itself forks once prior to
>>running popen(). execve() replaces the running process, so there's no
>
Actually, I made a mistake there. Only two fork()'s, as /bin/sh calls
execve() more or less immediately.
>
> that's the count that i got:
>
> - nagios forks
> - nagios child calls popen
> - popen forks
> - popen child calls execve(/bin/sh)
> - /bin/sh forks
Nopes.
> - /bin/sh child calls execve(cmd)
> - /bin/sh child (now cmd) exits with status
>
> and i'm suggesting
>
> - nagios forks
nagios child does a symbol lookup of plugin_function
> - nagios child calls plugin_function
> - nagios child exits return status of plugin_function
>
> note that if this were in a multi-threaded arch, or if the child
> processes were pre-allocated, even this fork would have a negligable
> effect.
>
No more negligable than what's already the case. I'm not sure what you
mean by multithreaded arch (multithreaded design, SMP machine?).
>
>>running popen(). execve() replaces the running process, so there's no
>>context-switching. It would be possible to get rid of one of the
>
>
> assuming that one fork() isn't avoidable, you still three processes
> between which you have to switch in the popen approach (nagios child,
> popen child, /bin/sh child).
>
nagios -> fork("pure" child) -> fork (popen) -> execve(/bin/sh -c) ->
execve(plugin).
Nothing else. I was wrong in my previous assessment.
>
>>Arguments can contain whitespace if escaped or enclosed in strings. Do
>>you feel like writing a function that does that and that's fast enough
>>to run as often as is required, while still being rock-solid safe? The
>>functions that does this in glibc and bash are asm-enhanced and
>>finetuned per architecture they're run at. You'd increase load
>>drastically, not reduce it.
>
>
> okay, so a little trickier than splitting on whitespace. however, i
> don't see where your concerns about speed/efficiency are coming from.
> why would we need to do this every time the command is executed? why
> not parse the cmd into arguments when the command is first read in from
> the conffile?
True. Didn't think of tha
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]