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