Failing event_handlers and ocsp/ochp_command silently fail & gged
Andreas Ericsson
ae at op5.se
Thu Aug 28 09:11:33 CEST 2008
Brian A. Seklecki wrote:
>
>> There's no problem with pipes. You may not agree with the standard, but
>> that's not a problem with pipes. It's a problem with you.
>
> AE: No need to make it personal.
>
> The problem is not pipes, the POSIX standard, or adherence to standards
> (*). It's how _pipes can obfuscate the problem_, and how letting
> handlers contain them can lead to to:
> - Obfuscation
> - Problems with escaping
> - Syntax problems
Those are, once again, problems with users mis-using an incredibly useful
feature. They're ofcourse free to use wrappers instead, and since the
format is so flexible they can do that without any problems what so ever.
I still haven't seen the actual problem with this, to be honest.
> ... calling a wrapper
Calling a wrapper is, for performance reasons, out of the question for
many large installations. Especially so for the OCSP/OCHP commands.
> or moving the code inside would solve some of this.
>
I'm not sure what you mean by this, but if you intend for Nagios to
handle pipe-chains internally, I'd say that would be a really dumb
idea, since it'd have to adhere to the exact same standard, or it would
confuse users who knows how pipes *should* behave.
>> Rather; Create a simple API that runs a process, storing everything
>> interesting in a publicly declared data structure and calls a
>> handler when the command is done executing.
>> Preferrably the API should have a shortcut to let in-core code feed
>> continuous input to it.
>
> Sounds fine. Or your other suggestion: Don't crunch 0,1,2,3 as health
> check results when not execing a healthcheck.
>
>
> ~BAS
>
> Although its not quite noon yet on the East coast yet, so I'll take a
> moment to bash on GNU/Linux and ignoring standards:
>
> My current favorite is GNU libc and fclose(3) will let you fclose() a
> null file pointer without error/warning (segfault is the expected
> result)
>
I'm not sure how old your glibc is. If you compile it with -DLIBIO_DEBUG
-DDEBUG_QUIET you get the behaviour you're talking about, but if you do
that you shouldn't really expect 100% standards conformant behaviour.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list